Re: [Python-Dev] Problems with the new super()
Hi, Guido van Rossum python.org> writes: > The staticmethod thing isn't new; that's also the case in 2.x. staticmethod hasn't changed, method has. In the past Class.method gave you a unbound method, now you get a function back as if it was a static method. > The super() thing is a case of practicality beats purity. Note that > you pay a small but measurable cost for the implicit __class__ (it's > implemented as a "cell variable", the same mechanism used for nested > scopes) so we wouldn't want to introduce it unless it is used. I do agree that super() is a lot easier to work with than regular way to call it. But the fact that it breaks if i do `_super = super` or that it's impossible to emulate it from within Python. Regards, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Invitation to try out open source code review tool
Some of you may have seen a video recorded in November 2006 where I showed off Mondrian, a code review tool that I was developing for Google (http://www.youtube.com/watch?v=sMql3Di4Kgc). I've always hoped that I could release Mondrian as open source, but it was not to be: due to its popularity inside Google, it became more and more tied to proprietary Google infrastructure like Bigtable, and it remained limited to Perforce, the commercial revision control system most used at Google. What I'm announcing now is the next best thing: an code review tool for use with Subversion, inspired by Mondrian and (soon to be) released as open source. Some of the code is even directly derived from Mondrian. Most of the code is new though, written using Django and running on Google App Engine. I'm inviting the Python developer community to try out the tool on the web for code reviews. I've added a few code reviews already, but I'm hoping that more developers will upload at least one patch for review and invite a reviewer to try it out. To try it out, go here: http://codereview.appspot.com Please use the Help link in the top right to read more on how to use the app. Please sign in using your Google Account (either a Gmail address or a non-Gmail address registered with Google) to interact more with the app (you need to be signed in to create new issues and to add comments to existing issues). Don't hesitate to drop me a note with feedback -- note though that there are a few known issues listed at the end of the Help page. The Help page is really a wiki, so feel free to improve it! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Module Suggestion: ast
Armin Ronacher schrieb: Hi all, I would like to propose a new module for the stdlib for Python 2.6 and higher: "ast". The motivation for this module is the pending deprecation for compiler.ast which is widely used (debugging, template engines, code coverage etc.). _ast is a very solid module and is without a doubt easier to maintain then compiler.ast which was written in Python, it's lacking some features such as pretty printing the AST or traversing it. If there are no further objections, I'll add this to PEP 361 so that the proposal doesn't get lost. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with the new super()
Armin Ronacher schrieb: The super() thing is a case of practicality beats purity. Note that you pay a small but measurable cost for the implicit __class__ (it's implemented as a "cell variable", the same mechanism used for nested scopes) so we wouldn't want to introduce it unless it is used. I do agree that super() is a lot easier to work with than regular way to call it. But the fact that it breaks if i do `_super = super` or that it's impossible to emulate it from within Python. That it isn't emulatable from Python doesn't bother me -- several functions have that property. But the other two magical things about super() really bother me too. I haven't looked at the new super in detail so far (and I don't know how many others have), and two things are really strikingly unpythonic in my view: * super() only works when named "super" [1]. It shouldn't be a function if it has that property; no other Python function has that. * "__class__" is magical in classes. If you define a local called "__class__" super won't work anymore in that function. Also, you can access "__class__" from any method, without the "self." qualifier -- another magical name. There may be more implications and surprising behavior surrounding this. I know that the implementation is a compromise, but I'd rather see a super() whose full semantics can be explained to programmers without using to "cell variable", "f_localsplus" and "symtable". cheers, Georg [1] Actually, it only works if a name "super" is accessed somewhere in the function, but this is what someone trying to alias "super" will perceive. -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Module properties for C modules
Guido van Rossum schrieb:
> But wouldn't this mean that those properties would no longer be
> available in the module's __dict__?
Correct. Module properties would behave exactly like instance
properties. They don't appear on the instance's __dict__ attribute, too.
By the way I was astonished that the vars() function dones't show
properties but dir() does list them.
>>> class Example(object):
... @property
... def x(self):
... return 42
...
>>> example = Example()
>>> example.__dict__
{}
>>> vars(example)
{}
>>> dir(example)
['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__',
'__hash__', '__init__', '__module__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__str__', '__weakref__', 'x']
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with the new super()
2008/5/1, Georg Brandl <[EMAIL PROTECTED]>: > There may be more implications and surprising behavior surrounding this. > > I know that the implementation is a compromise, but I'd rather see a > super() > whose full semantics can be explained to programmers without using to > "cell variable", "f_localsplus" and "symtable". In consideration of what's been said about super() in the past, and what is handled here regarding its Py3 implementation, I want to make a step back, and ask: Has super() proved more useful than harmful? Which is the value for Py3 to keep it? Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with the new super()
On Thu, May 1, 2008 at 11:20 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > But the other two magical things about super() really bother me too. I > haven't looked at the new super in detail so far (and I don't know how > many others have), and two things are really strikingly unpythonic in > my view: > > * super() only works when named "super" [1]. It shouldn't be a function if > it has that property; no other Python function has that. Actually, I believe IronPython and/or Jython have to use this trick in certain cases -- at least I recall Jim Hugunin talking about generating different code when the use of locals() was detected. I'm not proud of this, but I don't see a way around it. The alternative would be to make it a keyword, which seemed excessive (plus, it would be odd if super() were a keyword when self is not). There were long discussions about various possible ways to implement something like this, and they all had their downsides. (The PEP still isn't fixed to describe the status quo.) > * "__class__" is magical in classes. If you define a local called > "__class__" > super won't work anymore in that function. > > Also, you can access "__class__" from any method, without the "self." > qualifier -- another magical name. I don't mind this at all -- it's a name starting and ending with double underscores, so you shouldn't use it except for its defined semantics, which happen to be exactly what super needs. (I would have proposed __super__() to get an exception for that too, except that it's excessively ugly.) > There may be more implications and surprising behavior surrounding this. > > I know that the implementation is a compromise, but I'd rather see a > super() > whose full semantics can be explained to programmers without using to > "cell variable", "f_localsplus" and "symtable". You don't have to explain it that way at all. First you explain how the 2.x super(C, self) works. Then you explain that if you call it with no arguments, the arguments default to the current class object and the first argument of the current function. Only people wanting to write their own interpreter need to know more. > cheers, > Georg > > [1] Actually, it only works if a name "super" is accessed somewhere in the > function, but this is what someone trying to alias "super" will > perceive. To Facundo, who asks if we need super() at all: yes, we need it. You can't write decent multiple-inheritance code without it. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with the new super()
At 04:38 PM 5/1/2008 -0300, Facundo Batista wrote: Has super() proved more useful than harmful? For me, yes. I use it all the time. The only time I use explicit-target upcalls is in __init__ methods, and there usually only to skip a subclass' init or to explicitly manage a tricky bit of multiple inheritance. (Note, by the way, that you cannot safely write an upcall in a mixin class without super, so it can't safely be done away with, anyway.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with the new super()
2008/5/1 Facundo Batista <[EMAIL PROTECTED]>: > 2008/5/1, Georg Brandl <[EMAIL PROTECTED]>: > > > There may be more implications and surprising behavior surrounding > this. > > > > I know that the implementation is a compromise, but I'd rather see a > > super() > > whose full semantics can be explained to programmers without using to > > "cell variable", "f_localsplus" and "symtable". > > In consideration of what's been said about super() in the past, and > what is handled here regarding its Py3 implementation, I want to make > a step back, and ask: > > Has super() proved more useful than harmful? Which is the value for > Py3 to keep it? Since Python supports multiple inheritance, you can't get away from something like super. Alternatives for methods chaining to parent classes are 1. implicit/automatic (like C++, I think), 2. explicit/semi-automatic (python's super, on one form or another, 3. explicit manual (programmer has to manually keep track of everything). Of all these alternatives I prefer Python's super (in one form or another). 1 is too "magic", and 3 is too error prone and cumbersome. A better question would be, is multiple inheritance good or bad for programs? :-) I think many people's answer to the above would be, generally bad, but there are exceptions where it helps and can be justified. > > > Regards, > > -- > .Facundo > > Blog: http://www.taniquetil.com.ar/plog/ > PyAr: http://www.python.org/ar/ > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Module properties for C modules
On Thu, May 1, 2008 at 12:32 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
>
> > But wouldn't this mean that those properties would no longer be
> > available in the module's __dict__?
>
> Correct. Module properties would behave exactly like instance
> properties. They don't appear on the instance's __dict__ attribute, too.
>
> By the way I was astonished that the vars() function dones't show
> properties but dir() does list them.
"Astonished" sounds stronger than you probably meant it. :-)
> >>> class Example(object):
> ... @property
> ... def x(self):
> ... return 42
> ...
> >>> example = Example()
> >>> example.__dict__
> {}
> >>> vars(example)
> {}
> >>> dir(example)
> ['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__',
> '__hash__', '__init__', '__module__', '__new__', '__reduce__',
> '__reduce_ex__', '__repr__', '__setattr__', '__str__', '__weakref__', 'x']
They are intentionally different though -- dir() tries to give all the
attributes, while vars() only accesses __dict__.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Module properties for C modules
Guido van Rossum schrieb: > On Thu, May 1, 2008 at 12:32 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: >> Guido van Rossum schrieb: >> >>> But wouldn't this mean that those properties would no longer be >> > available in the module's __dict__? >> >> Correct. Module properties would behave exactly like instance >> properties. They don't appear on the instance's __dict__ attribute, too. >> >> By the way I was astonished that the vars() function dones't show >> properties but dir() does list them. > > "Astonished" sounds stronger than you probably meant it. :-) Slightly :) What's your opinion on the module properties idea? Do you still like it although the property values won't show up in __dict__? Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] shal we redefine "module" and "package"?
On Apr 30, 2008, at 5:11 PM, [EMAIL PROTECTED] wrote: I have a less disruptive counterproposal. How about just starting to refer to directories (or "folders", or zip entries) with '__init__.py' in them as "package modules"? A package is-a module anyway. That's a good idea. I belive a multi-word term here would be similarly more memorable and precise. A "package distribution" would include the more familiar term while still being specific, consistent with the old terminology, and correct. Using a qualifying word is probably a good idea in this context anyway. I usually say "debian package", "RPM", "MSI", or "tarball" unless I'm specifically talking about "packages for your platform", That's a good one too. almost always in the phrase, "please do not use distutils to do a system install of Twisted, use the specific package for your platform". This is a tangent, but why do you give that advice? I typically give people the opposite advice on how to install Twisted. I do, however, agree with Steve emphatically on your original proposal. Changing the terminology now will make billions upon billions of Python web pages, modules (c.f. twisted.python.modules.PythonModule.isPackage()) documents, and searchable message archives obsolete, not to mention that 90% of the community will probably ignore you and use the old terminology anyway, creating more confusion than it eliminates. I suspect 90% of the community already uses my proposed terminology -- that was my original challenge to round up a Python programmer and find out. But I agree that my proposal would contribute to confusion and disruption, and I like your counterproposals better, at least for now. Directories, folders, or zip entries with __init__.py in them are "package modules", and Python packages are "package distributions". Regards, Zooko ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a reminder that the LAST planned alpha releases of Python 2.6 and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be diligent over the next week so that none of your changes break Python. The stable buildbots look moderately okay, let's see what we can do about getting them all green: http://www.python.org/dev/buildbot/stable/ We have a few showstopper bugs, and I will be looking at these more carefully starting next week. http://bugs.python.org/[EMAIL PROTECTED],id,activity,versions,status&@sort=activity&@filter=priority,status&@pagesize=50&@startwith=0&priority=1&status=1&@dispname=Showstoppers Time is running short to get any new features into Python 2.6 and 3.0. The release after this one is scheduled to be the first beta release, at which time we will institute a feature freeze. If your feature doesn't make it in by then, you'll have to wait until 2.7/3.1. If there is something that absolutely must go into 2.6/3.0 be sure that there is a bug issue open for it and that the Priority is set to 'release blocker'. I may reduce it to critical for the next alpha, but we'll review all the release blocker and critical issues for the first 2.6 and 3.0 beta releases. Cheers, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSBonfHEjvBPtnXfVAQLaSwP+IMjYbLryACRColvgTU4ezPHhbBpdDaRA I2k15cLsqmkFwHitt9TaTlLklnZuETiEfl7pVzow20KW18Z2tWP5U5KVMrVVbrJM 9pMS/vC102FVD88ukyQcPP5q+pw2+r2qTLr3q/205zdELQlWo+Ny6ir6dAgTKOd4 /OZqgCMBHS4= =MhWr -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Module properties for C modules
On Thu, May 1, 2008 at 1:20 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > What's your opinion on the module properties idea? Do you still like it > although the property values won't show up in __dict__? I don't see how it could work if any Python code is executed in the module, since code execution uses a dict for globals. Supporting it only for built-in modules seems too big an exception. So I'm -0. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Module properties for C modules
Guido van Rossum schrieb: > I don't see how it could work if any Python code is executed in the > module, since code execution uses a dict for globals. > > Supporting it only for built-in modules seems too big an exception. I came up with the idea in order to replace the setters and getters of builtin modules such as the sys module. I deliberately excluded Python modules from the idea. It's going to be too tricky to expose the API to Python. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
Barry Warsaw schrieb: > This is a reminder that the LAST planned alpha releases of Python 2.6 > and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be > diligent over the next week so that none of your changes break Python. > The stable buildbots look moderately okay, let's see what we can do > about getting them all green: I like to draw some attention to two features for the last alpha: PEP 370: Per user site-packages directory http://www.python.org/dev/peps/pep-0370/ Alternative memory allocation for ints, floats and longs using PyMalloc instead of the current block allocation. The issue has been discussed in great length a few months ago but without a final decision. http://bugs.python.org/issue2039 Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Module Suggestion: ast
2008/5/1 Georg Brandl <[EMAIL PROTECTED]>: > Armin Ronacher schrieb: > > I would like to propose a new module for the stdlib for Python 2.6 > > and higher: "ast". > > If there are no further objections, I'll add this to PEP 361 so that the > proposal doesn't get lost. Excuse my confusion over process, but if this is to go into 2.6, does that mean it needs to be ready before the first beta? Or is there a more relaxed schedule for the stdlib (and if so, what is the deadline for the stdlib)? The same question probably applies to the stdlib reorg... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Invitation to try out open source code review tool
On Thu, May 1, 2008 at 2:42 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: > As I understood this,one needs a diff to comment on. > I can imagine wanting, or wanting others, to be able to comment on a file > or lines of files without making a fake diff (of the file versus itself or > a blank file). Then only one column would be needed. Yeah, this use case is not well supported. In my experience with the internal tool at Google, I don't think that anybody has ever requested that feature, so perhaps in practice it's not so common. I mean, who wants to review a 5000-line file once it's checked in? :-) The right point for such a review (certainly this is the case at Google) is when it goes in. > I presume the current site is for trial purposes. Actually I'm hoping to keep it alive forever, just evolving the functionality based on feedback. > You obviously don't want > hundreds of repositories listed. Repository management is a bit of an open problem. Fortunately, when you use upload.py, you don't need to have a repository listed -- upload.py will specify the correct base URL, especially for repositories hosted at Google. (I should probably figure out how to support SourceForge as well...) > Are you planning, for instance, to > suggest that Google project hosting add a Review tab or link to the project > pages? They've been following my release with interest... > And I followed the link to pages about Rietveld ;-) Thanks. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with the new super()
On Thu, May 01, 2008 at 12:55:22PM -0700, Guido van Rossum wrote: > > I'm not proud of this, but I don't see a way around it. The > alternative would be to make it a keyword, which seemed excessive > (plus, it would be odd if super() were a keyword when self is not). > There were long discussions about various possible ways to implement > something like this, and they all had their downsides. (The PEP still > isn't fixed to describe the status quo.) I remember some brainstorms about treating more like self. I'm not sure if these were thought through all the way, but I remember seeing something like: class MyClass(Super1, Super2): # This method requires super: @requires_super def __init__(self, super, **kwds): super(**kwds) # This method doesn't require super: def some_method(self): pass I'm sure there are drawbacks, but it fits in my head. Using super in Python 2.0 is verbose but simple. However, I'm a little scared of super in Python 3.0. I guess I'm probably just a wimp. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 signature.asc Description: Digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Invitation to try out open source code review tool
On Thu, May 1, 2008 at 4:24 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: > > "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > | On Thu, May 1, 2008 at 2:42 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: > | > As I understood this,one needs a diff to comment on. > | > I can imagine wanting, or wanting others, to be able to comment on a > file > | > or lines of files without making a fake diff (of the file versus > itself or > | > a blank file). Then only one column would be needed. > | > | Yeah, this use case is not well supported. In my experience with the > | internal tool at Google, I don't think that anybody has ever requested > | that feature, so perhaps in practice it's not so common. I mean, who > | wants to review a 5000-line file once it's checked in? :-) The right > | point for such a review (certainly this is the case at Google) is when > | it goes in. > > I am thinking of an entirely different scenario: a package of modules that > are maybe a few hundred lines each and that accompany a book and are meant > for human reading as much or more than for machine execution. > > Or this: 15 minutes ago I was reading a PEP and discovered that a link did > not work. So I find the non-clickable author email at the top and notify > the author with my email program. But how much nicer to double click an > adjacent line and stick the comment in place (and let your system do the > emailing). (I presume the sponsor of an item in your system can remove > no-longer-needed comments.) So I guess I am thinking of your system as one > for collaborative online editing rather than just patch review. I agree that those are all great use cases. Eventually we'll be able to support these; right now though, I'd like to focus on the more immediate need (IMO) of patch reviews. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Invitation to try out open source code review tool
It would be really nice to see support for some other backends, such as Hg or bzr (which are both written in python), in addition to svn. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Thu, May 1, 2008 at 2:27 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Barry Warsaw schrieb: > > > This is a reminder that the LAST planned alpha releases of Python 2.6 > > and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be > > diligent over the next week so that none of your changes break Python. > > The stable buildbots look moderately okay, let's see what we can do > > about getting them all green: > > I like to draw some attention to two features for the last alpha: > > PEP 370: Per user site-packages directory > http://www.python.org/dev/peps/pep-0370/ I like this, except one issue: I really don't like the .local directory. I don't see any compelling reason why this needs to be ~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide it from view, especially since the user is expected to manage this explicitly. > Alternative memory allocation for ints, floats and longs using PyMalloc > instead of the current block allocation. The issue has been discussed in > great length a few months ago but without a final decision. > http://bugs.python.org/issue2039 I might look at this later; but it seems to me to be a pure optimization and thus not required to be in before the first beta. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Invitation to try out open source code review tool
On Thu, May 1, 2008 at 4:37 PM, Neal Becker <[EMAIL PROTECTED]> wrote: > It would be really nice to see support for some other backends, such as Hg > or bzr (which are both written in python), in addition to svn. Once it's open source feel free to add those! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with the new super()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 1, 2008, at 6:33 PM, Andrew McNabb wrote: On Thu, May 01, 2008 at 12:55:22PM -0700, Guido van Rossum wrote: I'm not proud of this, but I don't see a way around it. The alternative would be to make it a keyword, which seemed excessive (plus, it would be odd if super() were a keyword when self is not). There were long discussions about various possible ways to implement something like this, and they all had their downsides. (The PEP still isn't fixed to describe the status quo.) I remember some brainstorms about treating more like self. I'm not sure if these were thought through all the way, but I remember seeing something like: class MyClass(Super1, Super2): # This method requires super: @requires_super def __init__(self, super, **kwds): super(**kwds) # This method doesn't require super: def some_method(self): pass I'm sure there are drawbacks, but it fits in my head. Using super in Python 2.0 is verbose but simple. However, I'm a little scared of super in Python 3.0. I guess I'm probably just a wimp. It certainly makes me uncomfortable too. I think of all the alternatives in PEP 3135, I'd probably prefer self.__super__.foo(), except that I'd call it self.super.foo(). Although I don't mind reserving a non-underscore-adorned name for Python 3.0, I could see adopting self.__super__ and using super(self).foo() as a shortcut. To me, that addresses the main rationale of the PEP without the magic (i.e. no need to repeat the class). - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSBpWLHEjvBPtnXfVAQJmOAP+NW1tj67Ls+m6PCbF9wYpPRQhT2RJ1210 0QdYxyYz8akY5+I1QJTp3BN5erDLw1sAWGcKVP2phw7Rvb3pXf8FGh/Yg8du7KAg ZAm96xdaNLPiATVDaZZHuoWZ3+S6zUbmx6QtpjU//EAOXhwQCoTdhDme9QyPDI/2 kA+oldSXr+M= =bBRP -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Module properties for C modules
On Thu, May 1, 2008 at 2:00 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Guido van Rossum schrieb: > > > I don't see how it could work if any Python code is executed in the > > module, since code execution uses a dict for globals. > > > > Supporting it only for built-in modules seems too big an exception. > > I came up with the idea in order to replace the setters and getters of > builtin modules such as the sys module. I deliberately excluded Python > modules from the idea. It's going to be too tricky to expose the API to > Python. Then I propose to drop the idea. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Invitation to try out open source code review tool
On Thu, 1 May 2008, Neal Becker wrote: > It would be really nice to see support for some other backends, such as Hg > or bzr (which are both written in python), in addition to svn. /me starts the clamour for git -- Cheers, Leif ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 1, 2008, at 7:45 PM, Guido van Rossum wrote: On Thu, May 1, 2008 at 2:27 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: Barry Warsaw schrieb: This is a reminder that the LAST planned alpha releases of Python 2.6 and 3.0 are scheduled for next Wednesday, 07-May-2008. Please be diligent over the next week so that none of your changes break Python. The stable buildbots look moderately okay, let's see what we can do about getting them all green: I like to draw some attention to two features for the last alpha: PEP 370: Per user site-packages directory http://www.python.org/dev/peps/pep-0370/ I like this, except one issue: I really don't like the .local directory. I don't see any compelling reason why this needs to be ~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide it from view, especially since the user is expected to manage this explicitly. Interesting. I'm of the opposite opinion. I really don't want Python dictating to me what my home directory should look like (a dot file doesn't count because so many tools conspire to hide it from me). I guess there's always $PYTHONUSERBASE, but I think I will not be alone. ;) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSBpYQ3EjvBPtnXfVAQLY+AP/dy7qoQKNEJiKtlwqCtw7LUCMLMQylBX8 DfbIonOnAaKHzjveyswuxVeAEq/C/fxssOGMhyd++H/1koJHjBdIHp47+RgohbHQ 1xCyA6Qj8f6xM3xdCR7lRuIDdjb6Tb/iCIQT/dHLrYxEf+VGUC+xVa3JIXdfJu4s kUYg7tU8SQ8= =xJWG -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On 11:45 pm, [EMAIL PROTECTED] wrote: I like this, except one issue: I really don't like the .local directory. I don't see any compelling reason why this needs to be ~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide it from view, especially since the user is expected to manage this explicitly. I've previously given a spirited defense of ~/.local on this list ( http://mail.python.org/pipermail/python-dev/2008-January/076173.html ) among other places. Briefly, "lib" is not the only directory participating in this convention; you've also got the full complement of other stuff that might go into an installation like /usr/local. So, while "lib" might annoy me a little, "bin etc games include lib lib32 man sbin share src" is going to get ugly pretty fast, especially if this is what comes up in Finder or Nautilus or Explorer every time I open a window. If it's going to be a visible directory on the grounds that this is a Python- specific thing that is explicitly *not* participating in a convention with other software, then please call it "~/Python" or something. Am I the only guy who finds software that insists on visible, fixed files in my home directory rude? vmware, for example, wants a "~/vmware" directory, but pretty much every other application I use is nice enough to use dotfiles (even cedega, with a roughly-comparable-to- lib "applications I've installed for you" folder). Put another way - it's trivial to make ~/.local/lib show up by symlinking ~/lib, but you can't make ~/lib disappear, and lots of software ends up looking at ~. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Thu, May 1, 2008 at 5:03 PM, <[EMAIL PROTECTED]> wrote: > On 11:45 pm, [EMAIL PROTECTED] wrote: > > > I like this, except one issue: I really don't like the .local > > directory. I don't see any compelling reason why this needs to be > > ~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide > > it from view, especially since the user is expected to manage this > > explicitly. > > > > I've previously given a spirited defense of ~/.local on this list ( > http://mail.python.org/pipermail/python-dev/2008-January/076173.html ) among > other places. > > Briefly, "lib" is not the only directory participating in this convention; > you've also got the full complement of other stuff that might go into an > installation like /usr/local. So, while "lib" might annoy me a little, "bin > etc games include lib lib32 man sbin share src" is going to get ugly pretty > fast, especially if this is what comes up in Finder or Nautilus or Explorer > every time I open a window. Unless I misread the PEP, there's only going to be a lib subdirectory. Python packages don't put stuff in other places AFAIK. On the Mac, the default Finder window is not your home directory but your Desktop, which is a subdirectory thereof with a markedly public name. In fact, OS X has a whole bunch of reserved names in your home directory, and none of them start with a dot. The rule seems to be that if it contains stuff that the user cares about, it doesn't start with a dot. > If it's going to be a visible directory on the > grounds that this is a Python- specific thing that is explicitly *not* > participating in a convention with other software, then please call it > "~/Python" or something. Much better than ~/.local/ IMO. > Am I the only guy who finds software that insists on visible, fixed files > in my home directory rude? vmware, for example, wants a "~/vmware" > directory, but pretty much every other application I use is nice enough to > use dotfiles (even cedega, with a roughly-comparable-to- lib "applications > I've installed for you" folder). The distinction to my mind is that most dot files (with the exception of a few like .profile or .bashrc) are not managed by most users -- the apps that manage them provide an APIs for manipulating their contents. (Sort of like thw Windows registry.) Non-dot files are for stuff that the user needs to be aware of. I'm not sure where Python packages fall, but ISTM that this is something a user must explicitly choose as the target of an installer. The user is also likely to have to dig through there to remove stuff, as Python package management doesn't have a way to remove packages. > Put another way - it's trivial to make ~/.local/lib show up by symlinking > ~/lib, That's not the same thing at all. > but you can't make ~/lib disappear, and lots of software ends up > looking at ~. But what software cares about another file there? My home directory is mostly a switching point where I have quick access to everything I access regularly. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with the new super()
Facundo Batista wrote: Has super() proved more useful than harmful? Which is the value for Py3 to keep it? Personally I've found exactly zero use cases for super() so far in my own code. A couple of times I thought I'd found one, but it turned out not to do quite what I wanted, and I ended up finding better solutions. So if it were up to me, I wouldn't be putting any effort into making it easier to use. I'm actually worried that making it too easy to use could lead people into using it when it's not appropriate. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with the new super()
Guido van Rossum wrote: The alternative would be to make it a keyword, which seemed excessive (plus, it would be odd if super() were a keyword when self is not). If it's really such a useful thing as to warrant so much magic to support it, then I think it deserves to have a keyword. Conversely, I would say that if it doesn't deserve a keyword, it also doesn't deserve that much magic. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with the new super()
Phillip J. Eby wrote: (Note, by the way, that you cannot safely write an upcall in a mixin class without super, so it can't safely be done away with, anyway.) It seems to me you can't safely write one in a mixin class *with* super either. I know that's what it's supposed to be for, but I can't see it working properly except under very special circumstances -- so special that they have never turned up in any code I've written so far. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with the new super()
Gustavo Carneiro wrote: A better question would be, is multiple inheritance good or bad for programs? :-) I would say there are good ways of using it, and bad ways of using it. In my experience, the good ways occur when the classes being mixed together are completely independent -- there is no overlap in method or instance variable names, and each class brings its own independent bundle of functionality to the party. If the classes being mixed clash or overlap in functionality somehow, the inheriting class needs to override all of the clashing methods and properties and resolve matters by delegating to one or another of the inherited classes (using explicit inherited method calls, not super!). If it's not feasible to do that for some reason, then you're better off forgetting about multiple inheritance and finding some other solution to the problem. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Thu, May 1, 2008 at 1:26 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This is a reminder that the LAST planned alpha releases of Python 2.6 and > 3.0 are scheduled for next Wednesday, 07-May-2008. Please be diligent over > the next week so that none of your changes break Python. The stable > buildbots look moderately okay, let's see what we can do about getting them > all green: > > http://www.python.org/dev/buildbot/stable/ > > We have a few showstopper bugs, and I will be looking at these more > carefully starting next week. > > > http://bugs.python.org/[EMAIL > PROTECTED],id,activity,versions,status&@sort=activity&@filter=priority,status&@pagesize=50&@startwith=0&priority=1&status=1&@dispname=Showstoppers > > Time is running short to get any new features into Python 2.6 and 3.0. The > release after this one is scheduled to be the first beta release, at which > time we will institute a feature freeze. If your feature doesn't make it in > by then, you'll have to wait until 2.7/3.1. If there is something that > absolutely must go into 2.6/3.0 be sure that there is a bug issue open for > it and that the Priority is set to 'release blocker'. I may reduce it to > critical for the next alpha, but we'll review all the release blocker and > critical issues for the first 2.6 and 3.0 beta releases. I just closed the release blocker I created (the backwards-compatibility issue with warnings.showwarning() ). I would like to add a PendingDeprecationWarning (or stronger) to 2.6 for showwarning() implementations that don't support the optional 'line' argument. I guess the best way to do it in C code would be to see if PyFunction_GetDefaults() returns a tuple of length two (since showwarning() already has a single optional argument as it is). Anyone have an issue with me doing this? Is PendingDeprecationWarning safe enough for 2.6? Or should this be a 3.0-only thing with a DeprecationWarning? -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Thu, May 1, 2008 at 9:31 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > > I just closed the release blocker I created (the > backwards-compatibility issue with warnings.showwarning() ). I would > like to add a PendingDeprecationWarning (or stronger) to 2.6 for > showwarning() implementations that don't support the optional 'line' > argument. I guess the best way to do it in C code would be to see if > PyFunction_GetDefaults() returns a tuple of length two (since > showwarning() already has a single optional argument as it is). > > Anyone have an issue with me doing this? Is PendingDeprecationWarning > safe enough for 2.6? Or should this be a 3.0-only thing with a > DeprecationWarning? I vote for a full DeprecationWarning. > > -Brett -- Cheers, Benjamin Peterson ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Guido van Rossum schrieb: On Thu, May 1, 2008 at 5:03 PM, <[EMAIL PROTECTED]> wrote: On 11:45 pm, [EMAIL PROTECTED] wrote: > I like this, except one issue: I really don't like the .local > directory. I don't see any compelling reason why this needs to be > ~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide > it from view, especially since the user is expected to manage this > explicitly. > I've previously given a spirited defense of ~/.local on this list ( http://mail.python.org/pipermail/python-dev/2008-January/076173.html ) among other places. Briefly, "lib" is not the only directory participating in this convention; you've also got the full complement of other stuff that might go into an installation like /usr/local. So, while "lib" might annoy me a little, "bin etc games include lib lib32 man sbin share src" is going to get ugly pretty fast, especially if this is what comes up in Finder or Nautilus or Explorer every time I open a window. Unless I misread the PEP, there's only going to be a lib subdirectory. Python packages don't put stuff in other places AFAIK. Maybe. But when I install other software in my homedir, I install it to ~/.local, precisely to avoid what Glyph said about getting the full set of subdirs, and it would be nice for Python to fit into this scheme. On the Mac, the default Finder window is not your home directory but your Desktop, which is a subdirectory thereof with a markedly public name. In fact, OS X has a whole bunch of reserved names in your home directory, and none of them start with a dot. The rule seems to be that if it contains stuff that the user cares about, it doesn't start with a dot. That's not my rule, and it seems that at least Barry and Glyph agree. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Module Suggestion: ast
Paul Moore schrieb: 2008/5/1 Georg Brandl <[EMAIL PROTECTED]>: Armin Ronacher schrieb: > I would like to propose a new module for the stdlib for Python 2.6 > and higher: "ast". If there are no further objections, I'll add this to PEP 361 so that the proposal doesn't get lost. Excuse my confusion over process, but if this is to go into 2.6, does that mean it needs to be ready before the first beta? Or is there a more relaxed schedule for the stdlib (and if so, what is the deadline for the stdlib)? The same question probably applies to the stdlib reorg... There is no feature freeze before the first beta. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On 01:55 am, [EMAIL PROTECTED] wrote: On Thu, May 1, 2008 at 5:03 PM, <[EMAIL PROTECTED]> wrote: Hi everybody. I apologize for writing yet another lengthy screed about a simple directory naming issue. I feel strongly about it but I encourate anyone who doesn't to simply skip it. First, some background: my strong feelings here are actually based on an experience I had a long time ago when helping someone with some C++ programming homework. They were baffled because when I helped them the programs compiled, but then as soon as they tried it on their own it didn't. The issue was that I had replicated my own autotools-friendly directory structure for them (at the time, "~/bin", "~/include", "~/lib", "~/etc", and so on managed with GNU stow) onto their machine and edited their shell setup to include them appropriately. But, as soon as I was finished, they "cleaned up" the "mess" I had left behind, and thereby removed all of their build dependencies. This was on a shared university build server, before the days of linux as a friendly, graphical operating system which encouraged you to look even more frequently at your home directory, so if anything I suspect the likelihood that this is a problem would be worse now. Since cleaning up my own home directory, of course, I find that I appreciate the lack of visual noise in Nautilus et. al. as well. Also, while I obviously think all tools should work this way, I think that Python in particular will attract an audience who is learning to program but not necessarily savvy with arcane nuances of filesystem layout, and it would be best if those details were abstracted. My concern here is for the naive python developer reading installation instructions off of a wiki and trying to get started with Twisted development. Seeing a directory created in your home directory (or, as the case may be, 3 directories, "bin", "lib", and "include") is a bit of a surprise. They don't actually care where the files in their installed library are, as long as they're "installed", and they can import them. However, they may care that clicking on the little house icon now shows not "Pictures", "Movies", etc, but "lib" (what's a 'lib'?) "bin" (what's a bin? is that like a box where I throw my stuff?) "share" (I put my stuff in "share", but it's not shared. Wait, I'm supposed to put it in "Public"?). Briefly, "lib" is not the only directory participating in this convention; you've also got the full complement of other stuff that might go into an installation like /usr/local. So, while "lib" might annoy me a little, "bin etc games include lib lib32 man sbin share src" is going to get ugly pretty fast, especially if this is what comes up in Finder or Nautilus or Explorer every time I open a window. Unless I misread the PEP, there's only going to be a lib subdirectory. Python packages don't put stuff in other places AFAIK. Python packages, at the very least, frequently put stuff in "bin" (or "scripts", I think, on Windows). Not all Python packages are pure- Python packages either; setup.py boasts --install-platlib, --install- headers, --install-data, and --exec-prefix options, which suggests an "include", "bin", and "share" directory, at least. I'm sure if I had more time to grovel around I'd find one that installed manpages. Twisted has some, but apparently setup.py doesn't do anything with them, we leave that to the OS packages... Of course, very little of this is handled by the PEP. But even the usage of the name "lib" implies that the PEP is taking some care to be compatible with an idiom that goes beyond Python itself here, or at least beyond simple Python packages. Even assuming that no Python library ever wanted to install any of these things, there are many Python libraries which are simply wrappers around lower-level libraries, and if I want to perform a per-user install of one of those, I am going to ./configure --prefix=~/something (and by "something", I mean ".local" ;)) and it would be nice to have Python living in the same space. For that matter it'd be nice to get autotools and Ruby and PHP and Perl and Emacs (ad nauseum) all looking at ~/.local as a mirror of /usr, so that I didn't have to write a bunch of shell bootstrap glue to get everything to behave consistently, or learn the new, special names for bits of configuration under "~" that are different from the ones under /usr/local or /etc. I replicate a consistent Python development environment with a ton of bizarre dependencies across something like 15 different OS installations (not to mention a bevy of virtual machines I keep around just for fun), so I think about these issues a lot. Most of these machines are macs and linux boxes, but I do my best on Windows too. FWIW I don't have any idea what the right thing to do is on Windows; ".local" doesn't particularly make sense, but neither does "lib" in that context. There's no rea
Re: [Python-Dev] Problems with the new super()
Guido van Rossum schrieb: On Thu, May 1, 2008 at 11:20 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: But the other two magical things about super() really bother me too. I haven't looked at the new super in detail so far (and I don't know how many others have), and two things are really strikingly unpythonic in my view: * super() only works when named "super" [1]. It shouldn't be a function if it has that property; no other Python function has that. Actually, I believe IronPython and/or Jython have to use this trick in certain cases -- at least I recall Jim Hugunin talking about generating different code when the use of locals() was detected. I don't know if it's possible in Jython to have "locals" referring to something else. For CPython, the name "super" in a function can refer to anything -- local, global or builtin -- and it just feels wrong for the compiler to make assumptions based on the mere mention of a non-reserved name. I'm not proud of this, but I don't see a way around it. The alternative would be to make it a keyword, which seemed excessive (plus, it would be odd if super() were a keyword when self is not). I don't find it odd. In fact, IMO the whole magic needed for the runtime implementation of "super()" justifies super becoming a keyword. Georg [Moving this to the Python-3000 list] -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
I stand corrected on a few points. You've convinced me that ~/lib/ is wrong. But I still don't like ~/.local/; not in the last place because it's not any more local than any other dot files or directories. The "symmetry" with /usr/local/ is pretty weak, and certainly won't help beginning users. As a compromise, I'm okay with ~/Python/. I would like to be able to say that the user explicitly has to set an environment variable in order to benefit from this feature, just like with $PYTHONPATH and $PYTHONSTARTUP. But that might defeat the point of making this easy to use for noobs. On OS X I think we should put this somewhere under ~/Library/. Just put it in a different place than where the Python framework puts its stuff. On Thu, May 1, 2008 at 8:25 PM, <[EMAIL PROTECTED]> wrote: > On 01:55 am, [EMAIL PROTECTED] wrote: > > > On Thu, May 1, 2008 at 5:03 PM, <[EMAIL PROTECTED]> wrote: > > > > Hi everybody. I apologize for writing yet another lengthy screed about a > simple directory naming issue. I feel strongly about it but I encourate > anyone who doesn't to simply skip it. > > First, some background: my strong feelings here are actually based on an > experience I had a long time ago when helping someone with some C++ > programming homework. They were baffled because when I helped them the > programs compiled, but then as soon as they tried it on their own it didn't. > The issue was that I had replicated my own autotools-friendly directory > structure for them (at the time, "~/bin", "~/include", "~/lib", "~/etc", and > so on managed with GNU stow) onto their machine and edited their shell setup > to include them appropriately. But, as soon as I was finished, they > "cleaned up" the "mess" I had left behind, and thereby removed all of their > build dependencies. This was on a shared university build server, before > the days of linux as a friendly, graphical operating system which encouraged > you to look even more frequently at your home directory, so if anything I > suspect the likelihood that this is a problem would be worse now. Since > cleaning up my own home directory, of course, I find that I appreciate the > lack of visual noise in Nautilus et. al. as well. > > Also, while I obviously think all tools should work this way, I think that > Python in particular will attract an audience who is learning to program but > not necessarily savvy with arcane nuances of filesystem layout, and it would > be best if those details were abstracted. > > My concern here is for the naive python developer reading installation > instructions off of a wiki and trying to get started with Twisted > development. Seeing a directory created in your home directory (or, as the > case may be, 3 directories, "bin", "lib", and "include") is a bit of a > surprise. They don't actually care where the files in their installed > library are, as long as they're "installed", and they can import them. > However, they may care that clicking on the little house icon now shows not > "Pictures", "Movies", etc, but "lib" (what's a 'lib'?) "bin" (what's a bin? > is that like a box where I throw my stuff?) "share" (I put my stuff in > "share", but it's not shared. Wait, I'm supposed to put it in "Public"?). > > > > > > > Briefly, "lib" is not the only directory participating in this > convention; > > > you've also got the full complement of other stuff that might go into an > > > installation like /usr/local. So, while "lib" might annoy me a little, > "bin > > > etc games include lib lib32 man sbin share src" is going to get ugly > pretty > > > fast, especially if this is what comes up in Finder or Nautilus or > Explorer > > > every time I open a window. > > > > > > > Unless I misread the PEP, there's only going to be a lib subdirectory. > > Python packages don't put stuff in other places AFAIK. > > > > Python packages, at the very least, frequently put stuff in "bin" (or > "scripts", I think, on Windows). Not all Python packages are pure- Python > packages either; setup.py boasts --install-platlib, --install- headers, > --install-data, and --exec-prefix options, which suggests an "include", > "bin", and "share" directory, at least. I'm sure if I had more time to > grovel around I'd find one that installed manpages. Twisted has some, but > apparently setup.py doesn't do anything with them, we leave that to the OS > packages... > > Of course, very little of this is handled by the PEP. But even the usage > of the name "lib" implies that the PEP is taking some care to be compatible > with an idiom that goes beyond Python itself here, or at least beyond simple > Python packages. > > Even assuming that no Python library ever wanted to install any of these > things, there are many Python libraries which are simply wrappers around > lower-level libraries, and if I want to perform a per-user install of one of > those, I am going to ./configure --prefix=~/something (and by "something", I > mean ".local" ;)) and it would be nice to
Re: [Python-Dev] Problems with the new super()
On May 1, 2008, at 9:21 PM, Greg Ewing wrote: If the classes being mixed clash or overlap in functionality somehow, the inheriting class needs to override all of the clashing methods and properties and resolve matters by delegating to one or another of the inherited classes (using explicit inherited method calls, not super!). Sorry but thats just not fair. It's not about convenience for the classes you're inheriting from, its so the inheriting class and superclasses can cooperate without requiring implementation details of one another. I agree that if your methods are 'clashing' then you are probably misinheriting, but cooperative methods can be the most natural way to model certain situations. Not to be dull but when building up a method from smaller reusable bits of functionality this is the case. Once you have explicitly stated the classes you want to inherit from, it isn't magic to expect some of their methods to chain without explicitly restating how exactly they should do that. In fact, doing so may make you more likely to make an error when you change which bits you want to include. If the method resolution order is there (and explicit somewhere) you might as well make use of it. If it's not feasible to do that for some reason, then you're better off forgetting about multiple inheritance and finding some other solution to the problem. Is it an issue of feasibility, or of what is the 'most obvious' solution? jared ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
-On [20080501 22:27], Barry Warsaw ([EMAIL PROTECTED]) wrote: >Time is running short to get any new features into Python 2.6 and >3.0. Is there a reliable way to identify 32-bits and 64-bits Windows from within Python? I have not found any yet, but it might be a mere oversight on my behalf. The reason I ask is that both return win32, which is most likely a reference to the API, even when having installed the 64 bits Python version. This, of course, by using win32 causes some issues with, for example, setuptools since it generate an egg with a win32 identifier. Now if you have Python C extension code it will be 64-bit compiled, thus not working on 32-bits Windows. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B All are lunatics, but he who can analyze his delusions is called a philosopher. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On 03:49 am, [EMAIL PROTECTED] wrote:
I stand corrected on a few points. You've convinced me that ~/lib/ is
wrong. But I still don't like ~/.local/; not in the last place because
it's not any more local than any other dot files or directories. The
"symmetry" with /usr/local/ is pretty weak, and certainly won't help
beginning users.
Why do you say the symmetry is weak? The name might not be that
evocative, but the main thrust of what I'm saying is that "~/."
should be an autotools-style directory layout. The symmetry I suggest
is in exactly that sense; that's what /usr/local is. I don't actually
care what "" is, except I (and many others) already use "local" for
that value, and the more software that honors it, the better. GNU stow
(arguably the king of per-user installation management) suggests ~/local
as an autotools --prefix target; the free desktop project implicitly
suggests ~/.local (by suggesting ~/.local/share is a place to put the
same files that would normally be searched for in /usr/share and
/usr/local/share). So the word "local" is just floating around in this
meme space; I don't like the word that much, but I don't see that
there's a different one which more clearly evokes the concept either. I
originally used "~/UNIX" and then ~/.unix, but switched to .local when I
noticed other folks doing it. One I've actually seen mentioned a few
times is "~/.nix-config", which I certainly don't think is any better.
It would help beginning users if ~/.local/bin and ~/.local/lib were
honored by the system. I, and other adherents of this idea that it
would be nice if users could install source without admin privs, have
been suggesting that to distro guys when I (we) can, and I figure in a
few years, somebody might bite. If that happens, it will start being
*easier* to build stuff from source into a separated location than to
need root, stomp on the system, and inevitably break some stuff.
Agitating for ~/Python/Platform/Libraries on $LD_LIBRARY_PATH (or
equivalent) is a lot harder to do with a straight face.
This is the reason I'm bothering to spill so many pixels on this topic;
I think it would be great if Python were the first real adopter of this
convention, and once *one* project has really gone full bore, each
subsequent one is progressively easier to convince. However, if you've
made up your mind on ~/Python, I think I've more than made my case at
this point, so I'll stop cluttering up the lists :).
(By the way, for what it's worth: I _hate_ the
bin/lib/etc/man/src/include naming convention mess, but it's a mess
which is programmatically honored in like a hundred billion lines of
code. This is why I want it supported, but hidden ;).)
As a compromise, I'm okay with ~/Python/. I would like to be able to
say that the user explicitly has to set an environment variable in
order to benefit from this feature, just like with $PYTHONPATH and
$PYTHONSTARTUP. But that might defeat the point of making this easy to
use for noobs.
Is there another point? It seems to me that this change is entirely
about shared conventions and "works by default" behavior. If you are
going to set an environment variable, set PYTHONPATH; it's already much
more flexible.
~/Python opens up some new problems though, although perhaps they are
trivially resolved: how should this interoperate with distutils? 'Just
make "python setup.py --user" do what "python setup.py --prefix
~/.local" would do' is pretty straightforward, but "~/Python" would need
a new convention. Should "~/Python" have a "~/Python/Scripts" directory
that one could add to $PATH? A "~/Python/Platform" directory, for
includes, libraries, other random junk like manpages or HTML docs?
~/Python/2.6/lib, or ~/Python2.6/lib?
To be fair, a separate, and purpose-designed Python directory layout
might also make certain things neater. For example one could support
parallel installation with Python2.6 (or Python/2.6) by giving each a
'lib' and 'bin' directory, and always having the scripts in the 2.6/bin
dir invoke the 2.6 interpreter, rather than having separated space for
libraries but having to mangle the names of scripts ("twistd8.0-py2.6").
I'd still prefer compatibility-by-convention with other tools,
languages, etc, though. In the long term, if everyone followed suit on
~/.local, that would be great. But I don't want a ~/Python, ~/Java,
~/Ruby, ~/PHP, ~/Perl, ~/OCaml and ~/Erlang and a $PATH as long as my
arm just so I can run a few applications without system-installing them.
On OS X I think we should put this somewhere under ~/Library/. Just
put it in a different place than where the Python framework puts its
stuff.
Isn't the whole point that it should be the same place? Under current
Python releases, OS X already has this functionality via
~/Library/Python/2.5/site-packages.
Also, I'd strongly suggest supporting both ~/Library (although the
existing location seems fine to me) *an
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
> Is there a reliable way to identify 32-bits and 64-bits Windows from > within Python? Not that I'm aware of. 'sys.platform=="win32" and "64 bits" in sys.version' will be reliable when it returns True, but it might be wrong when it returns False (although when it returns False, things will look a lot like a 32bit OS). The best way I can find for the win32 API to tell you this is a combination of the above and the IsWow64Process() (which returns True if you are a 32bit process on a 64bit platform) I'd be interested to know why you care though - ie, how will the behavior of your programs depend on that? The virtualization compatibility hacks which, best I can tell are currently enabled for Python mean that the answer to the question might not be as useful as people might think. But I'm sure valid reasons for wanting to know this exist, so I'd be happy to create a patch which add a new sys.iswow64process() process if desired. Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with the new super()
Jared Flatow wrote: I agree that if your methods are 'clashing' then you are probably misinheriting, but cooperative methods can be the most natural way to model certain situations. I'm not saying that nobody should ever use super, only that it's not the right thing for the situation I was talking about there. What it essentially comes down to is that classes mix well if they were designed to mix well. Keeping their features independent is one way to achieve that. Designing their methods to fit together in a super call chain is another, if you can manage to pull it off. All I was really trying to say is that stating that "multiple inheritance is bad" is far too simplistic. Is it an issue of feasibility, or of what is the 'most obvious' solution? I can only speak from my own experience, which is that whenever I've had a problem involving multiple inheritance, super() didn't solve it. What did solve it was either refactoring so that the classes being mixed were more independent, or finding another solution that didn't require multiple inheritance. Usually the new solution turned out to be better in other ways as well, so I've come to regard multiple inheritance issues as a code smell suggesting that I need to rethink something. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
> Is there a reliable way to identify 32-bits and 64-bits Windows from within > Python? I have not found any yet, but it might be a mere oversight on my > behalf. > > The reason I ask is that both return win32, which is most likely a reference > to the API, even when having installed the 64 bits Python version. This, of > course, by using win32 causes some issues with, for example, setuptools > since it generate an egg with a win32 identifier. Now if you have Python C > extension code it will be 64-bit compiled, thus not working on 32-bits > Windows. It seems you don't want to identify whether the Windows installation is a Win64 one, but whether the Python installation is, right? For this, you should use platform.architecture()[0] Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] socket.try_reuse_address()
On Wed, Apr 30, 2008 at 10:42 AM, Trent Nelson <[EMAIL PROTECTED]>
wrote:
> > if os.name == "nt":
> > _socketmethods = _socketmethods + ('ioctl',)
> > +_is_windows = True
> > +elif os.name == 'java':
> > +from java.lang import System
> > +_is_windows = 'windows' in System.getProperty('os.name').lower()
> > +elif os.name == 'posix' and sys.platform == 'cygwin':
> > +_is_windows = True
>
> Oops, that last line should have been:
>
> elif os.name == 'ce' or (os.name == 'posix' and sys.platform == 'cygwin'):
>_is_windows = True
>
Why even bother to check os.name == 'posix' doesn't sys.platform == 'cygwin'
mean its windows regardless of os.name?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
