Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2008-August.txt below:

element) and the results are sent back to the user. In my case I have lots of combinations of capabilities that can be mixed together. I decided to use multiple inheritance over other patterns because I wanted to leverage isinstance(obj,Y) to indicate that some object has some capability, and not having to duplicate the method resolution order code for other kinds of methods is really nice. > A non-contrived example or two would be a good thing to > have in tutorials etc. where super() is discussed. It > would help to convey the kinds of situations in which > use of super() is and is not appropriate. So this is a collection of cooperative classes, and super() isn't used. Joel From pje at telecommunity.com Thu Aug 28 20:54:08 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 28 Aug 2008 14:54:08 -0400 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com > References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> Message-ID: <20080828185312.943163A408D@sparrow.telecommunity.com> At 05:50 PM 8/28/2008 +0200, Michele Simionato wrote: >On Aug 28, 5:30 pm, "Phillip J. Eby" wrote: > > How is that making things easier for application programmers? > >We have different definitions of "application programmer". For me a typical >application programmer is somebody who never fiddles with metaclasses, >which are the realm of framework builders. Application programmers use frameworks, and sometimes more than one. If they're subclassing from two different frameworks, each using a different metaclass, they will need to also multiple-inherit the metaclass. This is in fact so annoying that I created a "universal metaclass" in DecoratorTools whose sole function is to delegate metaclass __new__, __init__, and __call__ to class-level methods (e.g. __class_new__, __class_call__, etc.), thereby eliminating the need to have custom metaclasses for most use cases in the first place. Now, wherever possible, I use that single metaclass in my frameworks, so that there's no need to mix them. That, IMO, would be a more useful change than getting rid of super(); it would get rid of the explicit metaclass mixing. (It would still not remove the need for co-operative methods, as the class-delegated methods still need to be co-operative for MI to work.) There are, of course, other ways to create co-operative function calls besides super(), and I've certainly created more a few of them in my time. (E.g. generic function method combination, instancemethod() chains, and next-method-iterators, to name the ones that occur to me right off.) But these are more for cases where super() is wholly inadequate to the purpose, and none are anywhere near as convenient as super(). From fuzzyman at voidspace.org.uk Thu Aug 28 21:31:16 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 28 Aug 2008 20:31:16 +0100 Subject: [Python-Dev] Documentation Error for __hash__ Message-ID: <48B6FD04.6080008@voidspace.org.uk> Hello all, The documentation for __hash__ seems to be outdated. I'm happy to submit a patch, so long as I am not misunderstanding something. http://docs.python.org/dev/reference/datamodel.html#object.__hash__ The documentation states: If a class does not define a __cmp__() or __eq__() method it should not define a __hash__() operation either; if it defines __cmp__() or __eq__() but not __hash__(), its instances will not be usable as dictionary keys. If a class defines mutable objects and implements a __cmp__() or __eq__() method, it should not implement __hash__(), since the dictionary implementation requires that a key?s hash value is immutable (if the object?s hash value changes, it will be in the wrong hash bucket). This may have been true for old style classes, but as new style classes inherit a default __hash__ from object - mutable objects *will* be usable as dictionary keys (hashed on identity) *unless* they implement a __hash__ method that raises a type error. Shouldn't the advice be that classes that implement comparison methods should always implement __hash__ (wasn't this nearly enforced?), and that mutable objects should raise a TypeError in __hash__. Additionally the following documentation states that __reversed__ is new in Python 2.6 and I think it was actually new in Python 2.4 (it certainly works for Python 2.5 and IronPython 1 which targets 2.4...). http://docs.python.org/dev/reference/datamodel.html#object.__reversed__ Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From tjreedy at udel.edu Thu Aug 28 21:59:44 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 28 Aug 2008 15:59:44 -0400 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> Message-ID: Michele Simionato wrote: > Notice that I was discussing an hypothetical language. I was arguing > that in principle > one could write a different language from Python, with single inheritance only, > and not lose much expressivity. I am not advocating any change to > current Python. Since this is a list for discussing changing current Python, you will have to excuse misunderstanding on that point. I do realize that you began with a concrete offer of improving the documentation of the super you hypothetically would like to be rid of ;-) From hall.jeff at gmail.com Thu Aug 28 22:42:18 2008 From: hall.jeff at gmail.com (Jeff Hall) Date: Thu, 28 Aug 2008 16:42:18 -0400 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B6FD04.6080008@voidspace.org.uk> References: <48B6FD04.6080008@voidspace.org.uk> Message-ID: <1bc395c10808281342v5d9a0d48sf748758a7b0fe6dd@mail.gmail.com> I'm not sure about the first but as for the __reversed__ we had a discussion yesterday and it was indeed added in 2.4 (oddly, my 2.5 documentation has this correct... ) -- Haikus are easy Most make very little sense Refrigerator -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Thu Aug 28 23:51:45 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 29 Aug 2008 07:51:45 +1000 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B6FD04.6080008@voidspace.org.uk> References: <48B6FD04.6080008@voidspace.org.uk> Message-ID: <48B71DF1.8020902@gmail.com> Michael Foord wrote: > This may have been true for old style classes, but as new style classes > inherit a default __hash__ from object - mutable objects *will* be > usable as dictionary keys (hashed on identity) *unless* they implement a > __hash__ method that raises a type error. > > Shouldn't the advice be that classes that implement comparison methods > should always implement __hash__ (wasn't this nearly enforced?), and > that mutable objects should raise a TypeError in __hash__. Hmm, I thought I fixed those docs when I did the PyObject_HashNotImplemented patch... (you can set __hash__ = None rather than raising a TypeError explicitly now so that collections.Hashable correctly returns False - the slot machinery in typeobject.c will then take of turning that into PyObject_HashNotImplemented at the C level). However, looking at the relevant checkins, it appears I only updated the C API docs and didn't correct the library or language references. I reopened http://bugs.python.org/issue2235 - there are some other doc fixes I need to do this weekend for RC1, so I can tackle this at the same time. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From tjreedy at udel.edu Thu Aug 28 23:55:14 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 28 Aug 2008 17:55:14 -0400 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <1bc395c10808281342v5d9a0d48sf748758a7b0fe6dd@mail.gmail.com> References: <48B6FD04.6080008@voidspace.org.uk> <1bc395c10808281342v5d9a0d48sf748758a7b0fe6dd@mail.gmail.com> Message-ID: Jeff Hall wrote: > I'm not sure about the first but as for the __reversed__ we had a > discussion yesterday and it was indeed added in 2.4 (oddly, my 2.5 > documentation has this correct... ) 2.4 doc: reversed( seq) Return a reverse iterator. seq must be an object which supports the sequence protocol (the __len__() method and the __getitem__() method with integer arguments starting at 0). New in version 2.4. [no mention of __reversed__] 3.3.6 Additional methods for emulation of sequence types [ditto] However, I confirmed that __reversed__ is used by reverse() class C: def __reversed__(self): return 'abc' c=C() print(reversed(c)) >>> abc From matt.giuca at gmail.com Fri Aug 29 00:00:06 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Fri, 29 Aug 2008 08:00:06 +1000 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B6FD04.6080008@voidspace.org.uk> References: <48B6FD04.6080008@voidspace.org.uk> Message-ID: > This may have been true for old style classes, but as new style classes > inherit a default __hash__ from object - mutable objects *will* be usable as > dictionary keys (hashed on identity) *unless* they implement a __hash__ > method that raises a type error. > I always thought this was a bug in new-style classes (due to the fact that, as you say, they inherit __hash__ from object whether it's wanted or not). However, it seems to be fixed in Python 3.0. So this documentation is only "wrong" for Python 2.x branch. See: Python 2.6b3+ (trunk:66055, Aug 29 2008, 07:50:39) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __eq__(self, other): ... return True ... >>> x = X() >>> hash(x) -1211564180 versus Python 3.0b3+ (py3k:66055M, Aug 29 2008, 07:52:23) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __eq__(self, other): ... return True ... >>> x = X() >>> hash(x) Traceback (most recent call last): File " ", line 1, in TypeError: unhashable type: 'X' Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Fri Aug 29 03:39:01 2008 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 29 Aug 2008 13:39:01 +1200 Subject: [Python-Dev] confusing exec error message in 3.0 In-Reply-To: <200808281121.15908.steve@pearwood.info> References: <200808281121.15908.steve@pearwood.info> Message-ID: <48B75335.6090502@canterbury.ac.nz> Steven D'Aprano wrote: > I don't think M.__file__ should lie and say it was loaded from a file > that it wasn't loaded from. It's useful to be able to look at a module > and see what file it was actually loaded from. On the other hand, it could be useful to be able to find the source file for a module, regardless of whether it was loaded from a .py, .pyc or .pyo. Maybe there should be a __source__ attribute for that? Or is os.path.splitext(M.__file__)[0] + ".py" considered good enough for that? -- Greg From ijmorlan at cs.uwaterloo.ca Fri Aug 29 03:50:14 2008 From: ijmorlan at cs.uwaterloo.ca (Isaac Morland) Date: Thu, 28 Aug 2008 21:50:14 -0400 (EDT) Subject: [Python-Dev] confusing exec error message in 3.0 In-Reply-To: <48B75335.6090502@canterbury.ac.nz> References: <200808281121.15908.steve@pearwood.info> <48B75335.6090502@canterbury.ac.nz> Message-ID: On Fri, 29 Aug 2008, Greg Ewing wrote: > Steven D'Aprano wrote: > >> I don't think M.__file__ should lie and say it was loaded from a file that >> it wasn't loaded from. It's useful to be able to look at a module and see >> what file it was actually loaded from. > > On the other hand, it could be useful to be able to find > the source file for a module, regardless of whether it > was loaded from a .py, .pyc or .pyo. > > Maybe there should be a __source__ attribute for that? > > Or is os.path.splitext(M.__file__)[0] + ".py" considered > good enough for that? I think .__source__ is a much better idea. It's more explicit to start with, and on top of that it can simply be None when there is no source file available, which is much more explicit than "file not found means no source file available". Also, if a feature is ever added to allow telling Python to put the compiled files in a separate tree (like javac -d directory in the Java universe) then it will be even more clear that computing the source location from __file__ is not the way to go. PS, in case it's not clear, I want that feature, in order to keep .pyc files out of my SVN checkouts. I hate having automatically generated files in my workspace. Isaac Morland CSCF Web Guru DC 2554C, x36650 WWW Software Specialist From guido at python.org Fri Aug 29 04:25:47 2008 From: guido at python.org (Guido van Rossum) Date: Thu, 28 Aug 2008 19:25:47 -0700 Subject: [Python-Dev] confusing exec error message in 3.0 In-Reply-To: References: <200808281121.15908.steve@pearwood.info> Message-ID: 2008/8/28 Steve Holden : > Guido van Rossum wrote: >> On Wed, Aug 27, 2008 at 6:21 PM, Steven D'Aprano wrote: >>> On Thu, 28 Aug 2008 08:39:01 am Georg Brandl wrote: >>>> Fredrik Lundh schrieb: >>>>> (using 3.0a4) >>>>> >>>>> >>> exec(open("file.py")) >>>>> >>>>> Traceback (most recent call last): >>>>> File " ", line 1, in >>>>> TypeError: exec() arg 1 must be a string, file, or code object, not >>>>> TextIOWrapper >>>>> >>>>> so what's "file" referring to here? >>>>> >>>>> (the above works under 2.5, of course) >>>> See http://bugs.python.org/issue1762972 -- it has been decided to >>>> drop that possibility. >>> Hmmm... I have a concern with one of the patches in that issue; I refer >>> to patch that changes the semantics of module's __file__ attribute. >>> >>> Guido noted that exec(open(M.__file__).read(), M.__dict__) almost worked >>> as a replacement for reload(), except that there were issues with file >>> extensions (.py, .pyc, .pyo and even things like .pyc24). So it was >>> decided that M.__file__ should always point to the source file. >>> >>> But now that reload() is now moved into the imp module, I don't see that >>> the justification for changing the semantics of M.__file__ still >>> exists. imp.reload(M) is much better for interactive use than >>> exec(open(M.__file__).read(), M.__dict__). >>> >>> Is there still a justification for having M.__file__ point to the source >>> even if the module was actually loaded from the .pyc version? If so, >>> what is that? >>> >>> Some years ago, as a newbie, I was having trouble with reload() >>> repeatedly not picking up changes I was making to a module. The problem >>> turned out to be user-error, but how I discovered that was by looking >>> at M.__file__ and noticing that Python was loading the .pyc file >>> instead of the .py file I was expecting. Had M.__file__ given >>> misleading information, I would have been mislead for much longer. >>> Here's a small contrived example under Python 2.5: >>> >>>>>> import parrot >>>>>> parrot.__file__ >>> 'parrot.py' >>>>>> # pretend that I made changes to the source >>> ... # in my editor, but forgot to save them >>> ... reload(parrot) >>> >>>>>> parrot.__file__ >>> 'parrot.pyc' >>> >>> >>> I don't think M.__file__ should lie and say it was loaded from a file >>> that it wasn't loaded from. It's useful to be able to look at a module >>> and see what file it was actually loaded from. >> >> While appreciate the use case, there are way more use cases where >> there's code that must painstakingly strip the trailing 'c' or 'o' >> from __file__ in order to read the source code. Perhaps we should have >> a separate API for finding out whether a module was loaded from source >> or from a .pyc file; but I think it would be better to have such an >> API somewhere in the imp module. It's also possible to follow what >> goes on by watching the verbose -v output. >> > Painstakingly? Surely the pain level isn't that high, and I agree with > Michael that the __file__ information would be better as the literal truth. Some people have custom mods to Python that change the extension, and then the c/o stripping code breaks. What is the literal truth depends on your use case. It is the literal truth that the source file is the .py file. -- --Guido van Rossum (home page: http://www.python.org/~guido/) -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele.simionato at gmail.com Fri Aug 29 06:07:27 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Fri, 29 Aug 2008 06:07:27 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <20080828185312.943163A408D@sparrow.telecommunity.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> Message-ID: <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> On Thu, Aug 28, 2008 at 8:54 PM, Phillip J. Eby wrote: > I created a "universal metaclass" in > DecoratorTools whose sole function is to delegate metaclass __new__, > __init__, and __call__ to class-level methods (e.g. __class_new__, > __class_call__, etc.), thereby eliminating the need to have custom > metaclasses for most use cases in the first place. Now, wherever possible, > I use that single metaclass in my frameworks, so that there's no need to mix > them. easy_installed DecoratorTools and found it: classy_class. >From the point of view of the code, this is a beautiful and elegant snippet. However, suppose that from tomorrow everybody starts using it. Since metaclasses would become so easy to use, possibly a lot of people would take advantage of them. Then we would have potentially complex (multiple) inheritance hierarchies with chains of methods (_class__new__/_class__init__) calling themselves cooperatively in the MRO. Would the resulting code be readable? How easy would be for an average framework user to understand what is happening to his class? I think class decorators would be a much better solution than classy_class for most use cases and we should push that way, not the cooperative inheritance way. Generally speaking I like more solutions bases on functional composition (as in WSGI that you know very well) than on method cooperation. Rather than improve the support for inheritance, I would like (in an ideal world) to reduce it, to make easier the choice for people between inheritance and alternatives (object composition, delegation, functional composition). In the real world, I am content in documenting the pitfalls of super, warn people about the dangers of complex design involving multiple inheritance and cooperation, and suggest alternatives. Michele Simionato From pje at telecommunity.com Fri Aug 29 06:22:39 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 29 Aug 2008 00:22:39 -0400 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.co m> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> Message-ID: <20080829042146.6DC123A408D@sparrow.telecommunity.com> At 06:07 AM 8/29/2008 +0200, Michele Simionato wrote: >On Thu, Aug 28, 2008 at 8:54 PM, Phillip J. Eby wrote: > > I created a "universal metaclass" in > > DecoratorTools whose sole function is to delegate metaclass __new__, > > __init__, and __call__ to class-level methods (e.g. __class_new__, > > __class_call__, etc.), thereby eliminating the need to have custom > > metaclasses for most use cases in the first place. Now, wherever possible, > > I use that single metaclass in my frameworks, so that there's no > need to mix > > them. > >easy_installed DecoratorTools and found it: classy_class. > >From the point of view of the code, this is a beautiful and elegant >snippet. However, suppose that from tomorrow everybody starts >using it. Since metaclasses would become so easy to use, possibly a >lot of people would take advantage of them. That was sort of the idea. ;-) > Then we would have >potentially complex (multiple) inheritance hierarchies with >chains of methods (_class__new__/_class__init__) calling >themselves cooperatively in the MRO. Would the resulting >code be readable? Readability's orthogonal. Some of them might be readable, some not. Depends on who's writing them. :) >How easy would be for an average framework user >to understand what is happening to his class? You're right, let's abolish inheritance, too, because then you might have to read more than one class to see what's happening. >I think class decorators would be a much better solution than >classy_class for most use cases Obviously, I disagree. :) You'll notice that DecoratorTools supports class decorators for Python 2.3 and up (actually, I think that particular bit worked in 2.2 as well). So, it's not the absence of class decorators that motivated the 'classy' mixin. >Generally speaking I like >more solutions bases on functional composition (as in WSGI >that you know very well) than on method cooperation. Rather than >improve the support for inheritance, I would like (in an ideal >world) to reduce it, to make easier the choice for people between >inheritance and alternatives (object composition, delegation, functional >composition). In the real world, I am content in documenting the >pitfalls of super, warn people about the dangers of complex >design involving multiple inheritance and cooperation, and suggest >alternatives. Naturally, if you can design a system to use delegates instead of class hierarchy to represent a chain of responsibility, it might well be an improvement. But there are tradeoffs, and no matter what you are going to end up coding chains of responsibility. Co-operative inheritance is a nice solution for chains of responsibility that can be expressed in a class hierarchy, and are no more "dangerous" than any other sort of chain of responsibility. In fact, they are in some ways less so since the patterns are likely to be better documented than anything you come up with on your own. From michele.simionato at gmail.com Fri Aug 29 06:44:24 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Fri, 29 Aug 2008 06:44:24 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <20080829042146.6DC123A408D@sparrow.telecommunity.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> <20080829042146.6DC123A408D@sparrow.telecommunity.com> Message-ID: <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> On Fri, Aug 29, 2008 at 6:22 AM, Phillip J. Eby wrote: > You're right, let's abolish inheritance, too, because then you might have to > read more than one class to see what's happening. You are joking, but I actually took this idea quite seriously. Once (four years ago or so) I did implement an object system from scratch in Scheme, completely without inheritance, to see how far it would go. It didn't go far, of course (nor I did expect it to go very far) but at least I learned exactly what (single) inheritance was good for. OTOH, for what concerns multiple inheritance, I am still not convinced it is really worth it. I mean, the MRO is beautiful, elegant and all that on paper, but on real-life code things as different, especially from the side of the users of frameworks heavily based on inheritance. > Naturally, if you can design a system to use delegates instead of class > hierarchy to represent a chain of responsibility, it might well be an > improvement. But there are tradeoffs, and no matter what you are going to > end up coding chains of responsibility. Agreed, it is all about tradeoffs. We have a different opinion on what a good tradeoff is in this case, but that's fine. I guess it depends on personal experience and the kind of code one has to work with. For instance I never had to integrated different frameworks using different metaclasses in my daily work, so I don't see a very strong case for classy_class over class decorators, but I could change my mind in the future, who knows? Anyway, It would be nice to have a good simple *real life* use case of cooperative inheritance not involving metaclasses, suitable for a beginners' tutorial about super, but I haven't found one yet :-( M.S. From mal at egenix.com Fri Aug 29 11:53:28 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 29 Aug 2008 11:53:28 +0200 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B6FD04.6080008@voidspace.org.uk> References: <48B6FD04.6080008@voidspace.org.uk> Message-ID: <48B7C718.7020802@egenix.com> On 2008-08-28 21:31, Michael Foord wrote: > Hello all, > > The documentation for __hash__ seems to be outdated. I'm happy to submit > a patch, so long as I am not misunderstanding something. > > http://docs.python.org/dev/reference/datamodel.html#object.__hash__ > > The documentation states: > > If a class does not define a __cmp__() or __eq__() method it should not > define a __hash__() operation either; if it defines __cmp__() or > __eq__() but not __hash__(), its instances will not be usable as > dictionary keys. If a class defines mutable objects and implements a > __cmp__() or __eq__() method, it should not implement __hash__(), since > the dictionary implementation requires that a key's hash value is > immutable (if the object's hash value changes, it will be in the wrong > hash bucket). > > > This may have been true for old style classes, but as new style classes > inherit a default __hash__ from object - mutable objects *will* be > usable as dictionary keys (hashed on identity) *unless* they implement a > __hash__ method that raises a type error. Being hashable is a different from being usable as dictionary key. Dictionaries perform the lookup based on the hash value, but will then have to check for hash collisions based on an equal comparison. If an object does not define an equal comparison, then it is not usable as dictionary key. > Shouldn't the advice be that classes that implement comparison methods > should always implement __hash__ (wasn't this nearly enforced?), It's probably a good idea to implement __hash__ for objects that implement comparisons, but it won't always work and it is certainly not needed, unless you intend to use them as dictionary keys. > and that mutable objects should raise a TypeError in __hash__. That's a good idea, even though it's not needed either ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 29 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From matt.giuca at gmail.com Fri Aug 29 13:03:22 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Fri, 29 Aug 2008 21:03:22 +1000 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B7C718.7020802@egenix.com> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> Message-ID: > Being hashable is a different from being usable as dictionary key. > > Dictionaries perform the lookup based on the hash value, but will > then have to check for hash collisions based on an equal comparison. > > If an object does not define an equal comparison, then it is not > usable as dictionary key. > But if an object defines *neither* __eq__ or __hash__, then by default it is usable as a dictionary key (using the id() of the object for both default equality and hashing, which is fine, and works for all user-defined types by default). An object defining __hash__ but not __eq__ is not problematic, since it still uses id() default for equality. (It just has potentially bad dictionary performance, if lots of things hash the same even though they aren't equal). This it not a problem by definition because *it is officially "okay" for two objects to hash the same, even if they aren't equal, though undesirable*. So all hashable objects are usable as dictionary keys, are they not? (As far as I know it isn't possible to have an object that does not have an equality comparison, unless you explicitly override __eq__ and have it raise a TypeError for some reason). It's probably a good idea to implement __hash__ for objects that > implement comparisons, but it won't always work and it is certainly > not needed, unless you intend to use them as dictionary keys. > But from what I know, it is a *bad* idea to implement __hash__ for any mutable object with non-reference equality (where equality depends on the mutable state), as an unbreakable rule. This is because if they are inserted into a dictionary, then mutated, they may suddenly be in the wrong bucket. This is why all the mutable types in Python with non-reference equality (eg. list, set, dict) are explicitly not hashable, while the immutable types (eg. tuple, frozenset, str) are hashable, and so are the mutable types with reference equality (eg. functions, user-defined classes by default). > > > and that mutable objects should raise a TypeError in __hash__. > > That's a good idea, even though it's not needed either ;-) > So I think my above "axioms" are a better (less restrictive, and still correct) rule than this one. It's OK for a mutable object to define __hash__, as long as its __eq__ doesn't depend upon its mutable state. For example, you can insert a function object into a dictionary, and mutate its closure, and it won't matter, because neither the hash nor the equality of the object is changing. It's only types like list and dict, with deep equality, where you run into this hash table problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Fri Aug 29 13:22:00 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 29 Aug 2008 12:22:00 +0100 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B7C718.7020802@egenix.com> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> Message-ID: <48B7DBD8.8070205@voidspace.org.uk> M.-A. Lemburg wrote: > On 2008-08-28 21:31, Michael Foord wrote: > >> Hello all, >> >> The documentation for __hash__ seems to be outdated. I'm happy to submit >> a patch, so long as I am not misunderstanding something. >> >> http://docs.python.org/dev/reference/datamodel.html#object.__hash__ >> >> The documentation states: >> >> If a class does not define a __cmp__() or __eq__() method it should not >> define a __hash__() operation either; if it defines __cmp__() or >> __eq__() but not __hash__(), its instances will not be usable as >> dictionary keys. If a class defines mutable objects and implements a >> __cmp__() or __eq__() method, it should not implement __hash__(), since >> the dictionary implementation requires that a key's hash value is >> immutable (if the object's hash value changes, it will be in the wrong >> hash bucket). >> >> >> This may have been true for old style classes, but as new style classes >> inherit a default __hash__ from object - mutable objects *will* be >> usable as dictionary keys (hashed on identity) *unless* they implement a >> __hash__ method that raises a type error. >> > > Being hashable is a different from being usable as dictionary key. > > Dictionaries perform the lookup based on the hash value, but will > then have to check for hash collisions based on an equal comparison. > > If an object does not define an equal comparison, then it is not > usable as dictionary key. > > >> Shouldn't the advice be that classes that implement comparison methods >> should always implement __hash__ (wasn't this nearly enforced?), >> > > It's probably a good idea to implement __hash__ for objects that > implement comparisons, but it won't always work and it is certainly > not needed, unless you intend to use them as dictionary keys. > > So you're suggesting that we document something like. Classes that represent mutable values and define equality methods are free to define __hash__ so long as you don't mind them being used incorrectly if treated as dictionary keys... Technically true, but not very helpful in my opinion... :-) Michael >> and that mutable objects should raise a TypeError in __hash__. >> > > That's a good idea, even though it's not needed either ;-) > > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From mal at egenix.com Fri Aug 29 14:43:11 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 29 Aug 2008 14:43:11 +0200 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> Message-ID: <48B7EEDF.70305@egenix.com> On 2008-08-29 13:03, Matt Giuca wrote: >> Being hashable is a different from being usable as dictionary key. >> >> Dictionaries perform the lookup based on the hash value, but will >> then have to check for hash collisions based on an equal comparison. >> >> If an object does not define an equal comparison, then it is not >> usable as dictionary key. >> > > But if an object defines *neither* __eq__ or __hash__, then by default it is > usable as a dictionary key (using the id() of the object for both default > equality and hashing, which is fine, and works for all user-defined types by > default). > > An object defining __hash__ but not __eq__ is not problematic, since it > still uses id() default for equality. (It just has potentially bad > dictionary performance, if lots of things hash the same even though they > aren't equal). This it not a problem by definition because *it is officially > "okay" for two objects to hash the same, even if they aren't equal, though > undesirable*. Note that only instances have the default hash value id(obj). This is not true in general. Most types don't implement the tp_hash slot and thus are not hashable. Indeed, mutable types should not implement that slot unless they know what they're doing :-) > So all hashable objects are usable as dictionary keys, are they not? (As far > as I know it isn't possible to have an object that does not have an equality > comparison, unless you explicitly override __eq__ and have it raise a > TypeError for some reason). Sorry, I wasn't clear enough: with "not defining an equal comparison" I meant that an equal comparison does not succeed, ie. raises an exception or returns Py_NotImplemented (at the C level). Due to the default of using the id(obj) as fallback for the equal comparison, this has to be explicitly coded for. If this is not the case (and that's probably the most common situation), then you're right: hashable implies usable as dictionary key. >> It's probably a good idea to implement __hash__ for objects that >> implement comparisons, but it won't always work and it is certainly >> not needed, unless you intend to use them as dictionary keys. >> > > But from what I know, it is a *bad* idea to implement __hash__ for any > mutable object with non-reference equality (where equality depends on the > mutable state), as an unbreakable rule. This is because if they are inserted > into a dictionary, then mutated, they may suddenly be in the wrong bucket. > This is why all the mutable types in Python with non-reference equality (eg. > list, set, dict) are explicitly not hashable, while the immutable types (eg. > tuple, frozenset, str) are hashable, and so are the mutable types with > reference equality (eg. functions, user-defined classes by default). Right. By implementing __hash__ in classes you have the explicit choice of either raising an exception or returning a useful hash value. Again, the situation is better at the C level, since types don't have a default tp_hash implementation, so have to explicitly code such a slot in order for hash(obj) to work. >>> and that mutable objects should raise a TypeError in __hash__. >> That's a good idea, even though it's not needed either ;-) >> > > So I think my above "axioms" are a better (less restrictive, and still > correct) rule than this one. It's OK for a mutable object to define > __hash__, as long as its __eq__ doesn't depend upon its mutable state. For > example, you can insert a function object into a dictionary, and mutate its > closure, and it won't matter, because neither the hash nor the equality of > the object is changing. It's only types like list and dict, with deep > equality, where you run into this hash table problem. I think the documentation needs to be changed to make the defaults explicit. The documentation should probably say: "If you implement __cmp__ or __eq__ on a class, also implement a __hash__ method (and either have it raise an exception or return a valid non-changing hash value for the object)." "If you implement __hash__ on classes, you should consider implementing __eq__ and/or __cmp__ as well, in order to control how dictionaries use your objects." In general, it's probably best to always implement both methods on classes, even if the application will just use one of them. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 29 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From matt.giuca at gmail.com Fri Aug 29 14:47:48 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Fri, 29 Aug 2008 22:47:48 +1000 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B7DBD8.8070205@voidspace.org.uk> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7DBD8.8070205@voidspace.org.uk> Message-ID: > >> It's probably a good idea to implement __hash__ for objects that >> implement comparisons, but it won't always work and it is certainly >> not needed, unless you intend to use them as dictionary keys. >> >> >> > > > So you're suggesting that we document something like. > > Classes that represent mutable values and define equality methods are free > to define __hash__ so long as you don't mind them being used incorrectly if > treated as dictionary keys... > > Technically true, but not very helpful in my opinion... :-) No, I think he was suggesting we document that if a class overrides __eq__, it's a good idea to also implement __hash__, so it can be used as a dictionary key. However I have issues with this. First, he said: "It's probably a good idea to implement __hash__ for objects that implement comparisons, but it won't always work and it is certainly not needed, unless you intend to use them as dictionary keys." You can't say "certainly not needed unless you intend to use them as dictionary keys", since if you are defining an object, you never know when someone else will want to use them as a dict key (or in a set, mind!) So *if possible*, it is a good idea to implement __hash__ if you are implementing __eq__. But also, it needs to be very clear that if you *should not* implement __hash__ on a mutable object -- and it already is. So basically the docs should suggest that it is a good idea to implement __hash__ if you are implementing __eq__ on an immutable object. HOWEVER, There are two contradictory pieces of information in the docs. a) "if it defines __cmp__() or __eq__() but not __hash__() , its instances will not be usable as dictionary keys." versus b) "User-defined classes have __cmp__() and __hash__() methods by default; with them, all objects compare unequal and x.__hash__() returns id(x)." Note that these statements are somewhat contradictory: if a class has a __hash__ method by default (as b suggests), then it isn't possible to "not have a __hash__" (as suggested by a). In Python 2, statement (a) is true for old-style classes only, while statement (b) is true for new style classes only. This distinction needs to be made. (For old-style classes, it isn't the case that it has a __hash__ method by default - rather that the hash() function knows how to deal with objects without a __hash__ method, by calling id()). In Python 3, statement (a) is true always, while statement (b) is not (in fact just the same as old-style classes are in Python 2). So the Python 3 docs can get away with being simpler (without having to handle that weird case). I just saw Marc-Andre's new email come in; I'll look at that now. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.giuca at gmail.com Fri Aug 29 15:07:25 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Fri, 29 Aug 2008 23:07:25 +1000 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B7EEDF.70305@egenix.com> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7EEDF.70305@egenix.com> Message-ID: > Note that only instances have the default hash value id(obj). This > is not true in general. Most types don't implement the tp_hash > slot and thus are not hashable. Indeed, mutable types should not > implement that slot unless they know what they're doing :-) By "instances" you mean "instances of user-defined classes"? (I carefully avoid the term "instance" on its own, since I believe that was phased out when they merged types and classes; it probably still exists in the C API but shouldn't be mentioned in Python-facing documentation). But anyway, yes, we should make that distinction. Sorry, I wasn't clear enough: with "not defining an equal comparison" > I meant that an equal comparison does not succeed, ie. raises an > exception or returns Py_NotImplemented (at the C level). Oh OK. I didn't even realise it was "valid" or "usual" to explicitly block __eq__ like that. > Again, the situation is better at the C level, since types > don't have a default tp_hash implementation, so have to explicitly > code such a slot in order for hash(obj) to work. Yes but I gather that this "data model" document we are talking about is not designed for C authors, but Python authors, so it should be written for the point of view of people coding only in Python. (Only the "Extending and Embedding" and the "C API" documents are for C authors). The documentation should probably say: > > "If you implement __cmp__ or > __eq__ on a class, also implement a __hash__ method (and either > have it raise an exception or return a valid non-changing hash > value for the object)." > I agree, except maybe not for the Python 3 docs. As long as the behaviour I am observing is well-defined and not just a side-effect which could go away -- that is, if you define __eq__/__cmp__ but not __hash__, in a user-defined class, it raises a TypeError -- then I think it isn't necessary to recommend implementing a __hash__ method and raising a TypeError. Better just to leave as-is ("if it defines __cmp__() or __eq__() but not __hash__() , its instances will not be usable as dictionary keys") and clarify the later statement. > > "If you implement __hash__ on classes, you should consider implementing > __eq__ and/or __cmp__ as well, in order to control how dictionaries use > your objects." I don't think I agree with that. I'm not sure why you'd implement __hash__ without __eq__ and/or __cmp__, but it doesn't cause issues so we may as well not address it. > In general, it's probably best to always implement both methods > on classes, even if the application will just use one of them. > Well it certainly is for new-style classes in the 2.x branch. I don't think you should implement __hash__ in Python 3 if you just want a non-hashable object (since this is the default behaviour anyway). A lot of my opinion here, though, which doesn't count very much -- so I'm just making suggestions. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From python-3000-list at trentnelson.com Fri Aug 29 13:30:08 2008 From: python-3000-list at trentnelson.com (Trent Nelson) Date: Fri, 29 Aug 2008 11:30:08 +0000 Subject: [Python-Dev] [Python-3000] what version of bsddb to use/accept for 2.6/3.0 In-Reply-To: References: Message-ID: <20080829113008.GA29787@wind.teleri.net> On Sun, Aug 24, 2008 at 06:15:06PM -0700, Neal Norwitz wrote: > It looks like the WIndows buildbots use 4.4.20. Unfortunately, the > Windows bots aren't in great shape either. It won't be that hard to bump 3.0 on Windows to use 4.7 (assuming that the 3.0 bsddb codebase has Jesus's new code). I'll be able to take a look at this early next week. Trent. From ncoghlan at gmail.com Fri Aug 29 18:04:52 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 30 Aug 2008 02:04:52 +1000 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7DBD8.8070205@voidspace.org.uk> Message-ID: <48B81E24.2070906@gmail.com> Matt Giuca wrote: > > > It's probably a good idea to implement __hash__ for objects that > implement comparisons, but it won't always work and it is certainly > not needed, unless you intend to use them as dictionary keys. > > > > > > So you're suggesting that we document something like. > > Classes that represent mutable values and define equality methods > are free to define __hash__ so long as you don't mind them being > used incorrectly if treated as dictionary keys... > > Technically true, but not very helpful in my opinion... :-) > > > No, I think he was suggesting we document that if a class overrides > __eq__, it's a good idea to also implement __hash__, so it can be used > as a dictionary key. I strongly advise people interested in this topic to take a closer look at the functionality that was added to address issue 2235. The "don't inherit __hash__" behaviour has been backported from 3.0 and broke a bunch of code, but the naive fix of reverting to the 2.5 behaviour proceeded to make the 2.6 version of collections.Hashable completely useless (since pretty much *everything* then claimed to be hashable, including all of the container types in the standard library). After thrashing out those problems, the 2.6 behaviour ended up being: - __hash__ is still inherited by default - you can block inheritance explicitly by setting "__hash__ = None" in the class definition or on the class object - for a class defined in C, you can block __hash__ inheritance by setting the tp_hash slot to PyObject_HashNotImplemented - using one of the above approaches will cause hash(obj) to raise a TypeError, as will calling the tp_hash slot directly - unlike defining your own __hash__ method, using one of the above techniques will also mean that isinstance(obj, collections.Hashable) will also return False - defining __eq__ and/or __cmp__ without defining __hash__ will lead to a Py3k Warning being raised on the class definition when run with the -3 switch The Python 3.0 behaviour is similar to the above, except that the unconditional inheritance of __hash__ is gone. If you define __eq__ or __cmp__ without defining __hash__, __hash__ will NOT be inherited from the parent class - instead, it will be set to None. The documentation of all of this could definitely use a bit more work - that's why I reopened 2235 in response to Michael's post. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From status at bugs.python.org Fri Aug 29 18:06:34 2008 From: status at bugs.python.org (Python tracker) Date: Fri, 29 Aug 2008 18:06:34 +0200 (CEST) Subject: [Python-Dev] Summary of Python tracker Issues Message-ID: <20080829160634.CBBD978357@psf.upfronthosting.co.za> ACTIVITY SUMMARY (08/22/08 - 08/29/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2029 open (+66) / 13524 closed (+16) / 15553 total (+82) Open issues with patches: 655 Average duration of open issues: 704 days. Median duration of open issues: 1760 days. Open Issues Breakdown open 2015 (+65) pending 14 ( +1) Issues Created Or Reopened (84) _______________________________ __eq__ / __hash__ check doesn't take inheritance into account 08/28/08 http://bugs.python.org/issue2235 reopened ncoghlan patch Objects/obmalloc.c:529: warning: comparison is always false due 08/24/08 http://bugs.python.org/issue3642 reopened christian.heimes 64bit IA5 Encoding should be in the default encodings 08/22/08 CLOSED http://bugs.python.org/issue3649 created pascal.bach Memory leak in bytes.split() 08/22/08 CLOSED http://bugs.python.org/issue3650 created amaury.forgeotdarc patch, needs review eval() leaks 1 reference every time 08/22/08 CLOSED http://bugs.python.org/issue3651 created amaury.forgeotdarc patch, needs review Remove DeprecationWarning in _warnings about 'line' 08/23/08 http://bugs.python.org/issue3652 created brett.cannon segfault calling sys.excepthook with non-Exception argument 08/23/08 CLOSED http://bugs.python.org/issue3653 created ajaksu2 patch, needs review Duplicated test name in regex test script 08/23/08 CLOSED http://bugs.python.org/issue3654 created mrabarnett latexwriter: \footnotemark can only take numbers as arguments 08/23/08 http://bugs.python.org/issue3655 created pv unicode encoding has lots of leaks of bytes 08/24/08 CLOSED http://bugs.python.org/issue3656 created nnorwitz pickle can pickle the wrong function 08/24/08 http://bugs.python.org/issue3657 created nnorwitz fix for pychecker property complaints 08/24/08 http://bugs.python.org/issue3658 created skip.montanaro patch, easy, needs review sqlite: enumeration value 'TYPE_STRING' not handled in switch 08/24/08 http://bugs.python.org/issue3659 created christian.heimes reference leaks in 3.0 08/24/08 http://bugs.python.org/issue3660 created nnorwitz patch sys.call_tracing segfaults 08/24/08 http://bugs.python.org/issue3661 created ajaksu2 _fileio._FileIO segfaults 08/24/08 CLOSED http://bugs.python.org/issue3662 created ajaksu2 needs review Extra DECREF on syntax errors 08/24/08 CLOSED http://bugs.python.org/issue3663 created amaury.forgeotdarc patch, needs review Pickler.dump from a badly initialized Pickler segfaults 08/24/08 http://bugs.python.org/issue3664 created ajaksu2 Support \u and \U escapes in regexes 08/24/08 http://bugs.python.org/issue3665 created georg.brandl patch atexit.register with bad input segfaults on exit 08/24/08 http://bugs.python.org/issue3666 created ajaksu2 Reloading an extension module always leaks 08/24/08 http://bugs.python.org/issue3667 created amaury.forgeotdarc patch, needs review "s*" argument parser marker leaks memory 08/24/08 http://bugs.python.org/issue3668 created amaury.forgeotdarc patch, needs review sqlite3.Connection.iterdump docs pythonicity 08/24/08 http://bugs.python.org/issue3669 created lehmannro patch Reporting bugs - no such sections 08/24/08 CLOSED http://bugs.python.org/issue3670 created kjohnson What's New in 2.6 - corrections 08/24/08 http://bugs.python.org/issue3671 created kjohnson Ill-formed surrogates not treated as errors during encoding/deco 08/24/08 http://bugs.python.org/issue3672 created Rhamphoryncus bsddb module leaks memory 08/25/08 http://bugs.python.org/issue3673 created nnorwitz patch, patch test_dbm_ndbm skip is unexpected on win32? 08/25/08 http://bugs.python.org/issue3674 created ocean-city patch Python 2.6 can't read sets pickled with Python 3.0 08/25/08 http://bugs.python.org/issue3675 created hagen patch Obsolete references to PEP 291 in py3k lib 08/25/08 http://bugs.python.org/issue3676 created orent importing from UNC roots doesn't work 08/25/08 http://bugs.python.org/issue3677 created krisvale Ignored LDFLAGS during linking libpython$(VERSION).so 08/25/08 http://bugs.python.org/issue3678 created Arfrever patch, easy, needs review pressing HOME key in IDLE editor ends IDLE 08/25/08 http://bugs.python.org/issue3679 created tjd Cycles with some iterator are leaking. 08/25/08 http://bugs.python.org/issue3680 created schuppenies patch Cannot read saved csv file in a single run 08/25/08 http://bugs.python.org/issue3681 created paul test_math: math.log(-ninf) fails to raise exception on OpenBSD 08/26/08 http://bugs.python.org/issue3682 created djmdjm compilation --without-threads fails 08/26/08 http://bugs.python.org/issue3683 created djmdjm needs review traceback.format_exception_only() misplaces the caret for certai 08/26/08 http://bugs.python.org/issue3684 created brodierao patch Crash while compiling Python 3000 in OpenBSD 4.4 08/26/08 http://bugs.python.org/issue3685 created henry.precheur patch PKG-INFO file should differentiate between authors and maintaine 08/26/08 http://bugs.python.org/issue3686 created lemburg Popen() object stdout attribute reassignment behaviour 08/26/08 http://bugs.python.org/issue3687 created vincent.legoll open() rejects bytes as filename 08/26/08 CLOSED http://bugs.python.org/issue3688 created dlitz listreverseiterator has a decreasing len() 08/26/08 http://bugs.python.org/issue3689 created laxrulz777 sys.getsizeof wrong for Py3k bool objects 08/26/08 http://bugs.python.org/issue3690 created schuppenies patch Incorrect variable reference 08/26/08 CLOSED http://bugs.python.org/issue3691 created timh improper scope in list comprehension, when used in class declara 08/26/08 CLOSED http://bugs.python.org/issue3692 created kaizhu Obscure array.array error message 08/27/08 http://bugs.python.org/issue3693 created tjreedy Undetected error in _struct.pack_into 08/27/08 http://bugs.python.org/issue3694 created ajaksu2 patch Source tarball for Sphinx 0.4.3 missing 08/27/08 http://bugs.python.org/issue3695 created hircus Error parsing arguments on OpenBSD <= 4.4 08/27/08 http://bugs.python.org/issue3696 created henry.precheur patch, needs review "Fatal Python error: Cannot recover from stack overflow" on Wind 08/27/08 http://bugs.python.org/issue3697 created pitrou patch, needs review incompatible arguments in warning formatting for idle 08/27/08 http://bugs.python.org/issue3698 created gcoffin test_bigaddrspace broken 08/27/08 http://bugs.python.org/issue3699 created pitrou test_bigmem broken 08/27/08 http://bugs.python.org/issue3700 created pitrou test_ntpath.test_relpath fails when launched from a different Wi 08/27/08 http://bugs.python.org/issue3701 created pitrou test_urllib2.test_trivial fails when run from another Windows dr 08/27/08 http://bugs.python.org/issue3702 created pitrou open() on directory raises IOError with unhelpful message 08/27/08 http://bugs.python.org/issue3703 created hagen patch, needs review cookielib doesn't handle URLs with / in parameters 08/27/08 http://bugs.python.org/issue3704 created andyk patch, needs review py3k aborts if "-c" or "-m" is given a non-ascii value 08/27/08 http://bugs.python.org/issue3705 created pitrou patch, needs review Fix error message for wrong exec() argument type 08/27/08 CLOSED http://bugs.python.org/issue3706 created georg.brandl patch, patch, needs review help('finally') behaves bizarrely 08/27/08 http://bugs.python.org/issue3707 created ms patch, easy, needs review os.urandom(1.1): infinite loop 08/27/08 http://bugs.python.org/issue3708 created ajaksu2 patch, easy, needs review BaseHTTPRequestHandler innefficient when sending HTTP header 08/27/08 http://bugs.python.org/issue3709 created yangman Reference leak in thread._local 08/28/08 http://bugs.python.org/issue3710 created tamino patch docs still say to use .dll for compiled extensions 08/28/08 CLOSED http://bugs.python.org/issue3711 created gagenellina patch memoryview leaks references 08/28/08 http://bugs.python.org/issue3712 created amaury.forgeotdarc patch, needs review Compile warning for Objects/stringlib 08/28/08 CLOSED http://bugs.python.org/issue3713 created kirkshorts patch nntplib module broken by str to unicode conversion 08/28/08 http://bugs.python.org/issue3714 created hdima patch hashlib's docstring throws exception in pydoc 08/28/08 http://bugs.python.org/issue3715 created erickt mistake in 3.4.2 Customizing attribute access 08/28/08 http://bugs.python.org/issue3716 created Alex7564 Py_InitModule* is still referenced in docs 08/28/08 http://bugs.python.org/issue3717 created erickt environment variable MACHDEP and python build system 08/28/08 http://bugs.python.org/issue3718 created rpetrov patch platform.py: _syscmd_file() can't handle target path with space 08/29/08 http://bugs.python.org/issue3719 created jfdp segfault in for loop with evil iterator 08/29/08 http://bugs.python.org/issue3720 created gideon patch, needs review invalid literal for int() with base 16: '' 08/29/08 http://bugs.python.org/issue3721 created xhomol11 print followed by exception eats print with doctest 08/29/08 http://bugs.python.org/issue3722 created cjw296 Py_NewInterpreter does not work 08/29/08 http://bugs.python.org/issue3723 created amaury.forgeotdarc math.log(x, 10) gives different result than math.log10(x) 08/29/08 http://bugs.python.org/issue3724 created segfaulthunter patch telnetlib module broken by str to unicode conversion 08/29/08 http://bugs.python.org/issue3725 created hdima Allow ', ' delimiters in logging.config.fileConfig() 08/29/08 http://bugs.python.org/issue3726 created wcmaier patch poplib module broken by str to unicode conversion 08/29/08 http://bugs.python.org/issue3727 created hdima imaplib module broken by str to unicode conversion 08/29/08 CLOSED http://bugs.python.org/issue3728 created hdima SystemError on calling len() if __len__() doesn't return an int 08/29/08 http://bugs.python.org/issue3729 created hagen patch Update BaseHTTPServer docs 08/29/08 http://bugs.python.org/issue3730 created catlee Issues Now Closed (35) ______________________ LookupError: unknown encoding: X-MAC-JAPANESE 317 days http://bugs.python.org/issue1276 lemburg patch Error using >>> from OpenGL.GLUT import * 301 days http://bugs.python.org/issue1346 igorcamp Using __(get|set|del)slice__ needs a Py3K warning 160 days http://bugs.python.org/issue2351 benjamin.peterson patch, needs review Fixer to handle new places where parentheses are needed 158 days http://bugs.python.org/issue2367 benjamin.peterson patch, 26backport bytes() should respect __bytes__ 161 days http://bugs.python.org/issue2415 benjamin.peterson patch, needs review urllib2 can't handle http://www.wikispaces.com 157 days http://bugs.python.org/issue2464 orsenthil patch Restore isinstance and issubclass speed in 2.6 147 days http://bugs.python.org/issue2534 pitrou patch, patch, needs review Locking should be removed from the new buffer protocol 80 days http://bugs.python.org/issue3046 teoliphant patch bytearrays are not thread safe 66 days http://bugs.python.org/issue3139 pitrou patch multiprocessing build fails on Solaris 10 68 days http://bugs.python.org/issue3149 pitrou 2to3 Fix_imports optimization 59 days http://bugs.python.org/issue3218 benjamin.peterson patch invalid call to PyMem_Free() in fileio_init() 49 days http://bugs.python.org/issue3304 nnorwitz patch, easy making partial functions comparable 7 days http://bugs.python.org/issue3564 tjreedy SPAM 5 days http://bugs.python.org/issue3579 tjreedy invalid exception context 8 days http://bugs.python.org/issue3611 amaury.forgeotdarc patch, needs review shutil.rmtree() fails on invalid filename 8 days http://bugs.python.org/issue3616 pitrou test issues on 64bit windows 2 days http://bugs.python.org/issue3625 mhammond patch, patch, 64bit apple security patches need to be forward ported to py3k 3 days http://bugs.python.org/issue3627 nnorwitz Add more checks to testcapi 2 days http://bugs.python.org/issue3643 benjamin.peterson patch IA5 Encoding should be in the default encodings 3 days http://bugs.python.org/issue3649 pascal.bach Memory leak in bytes.split() 0 days http://bugs.python.org/issue3650 amaury.forgeotdarc patch, needs review eval() leaks 1 reference every time 4 days http://bugs.python.org/issue3651 benjamin.peterson patch, needs review segfault calling sys.excepthook with non-Exception argument 1 days http://bugs.python.org/issue3653 benjamin.peterson patch, needs review Duplicated test name in regex test script 1 days http://bugs.python.org/issue3654 georg.brandl unicode encoding has lots of leaks of bytes 0 days http://bugs.python.org/issue3656 amaury.forgeotdarc _fileio._FileIO segfaults 0 days http://bugs.python.org/issue3662 nnorwitz needs review Extra DECREF on syntax errors 2 days http://bugs.python.org/issue3663 pitrou patch, needs review Reporting bugs - no such sections 0 days http://bugs.python.org/issue3670 kjohnson open() rejects bytes as filename 0 days http://bugs.python.org/issue3688 amaury.forgeotdarc Incorrect variable reference 0 days http://bugs.python.org/issue3691 benjamin.peterson improper scope in list comprehension, when used in class declara 0 days http://bugs.python.org/issue3692 georg.brandl Fix error message for wrong exec() argument type 0 days http://bugs.python.org/issue3706 georg.brandl patch, patch, needs review docs still say to use .dll for compiled extensions 0 days http://bugs.python.org/issue3711 georg.brandl patch Compile warning for Objects/stringlib 0 days http://bugs.python.org/issue3713 christian.heimes patch imaplib module broken by str to unicode conversion 0 days http://bugs.python.org/issue3728 hdima Top Issues Most Discussed (10) ______________________________ 23 eval() leaks 1 reference every time 4 days closed http://bugs.python.org/issue3651 10 "s*" argument parser marker leaks memory 5 days open http://bugs.python.org/issue3668 9 import of site.py fails on startup 57 days open http://bugs.python.org/issue3279 8 Restore isinstance and issubclass speed in 2.6 147 days closed http://bugs.python.org/issue2534 7 Error parsing arguments on OpenBSD <= 4.4 2 days open http://bugs.python.org/issue3696 7 IA5 Encoding should be in the default encodings 3 days closed http://bugs.python.org/issue3649 6 os.urandom(1.1): infinite loop 2 days open http://bugs.python.org/issue3708 6 Objects/obmalloc.c:529: warning: comparison is always false due 5 days open http://bugs.python.org/issue3642 6 test_cpickle crash on AMD64 Windows build 8 days open http://bugs.python.org/issue3640 6 python3.0 interpreter on Cygwin ignores all arguments 8 days open http://bugs.python.org/issue3626 From ncoghlan at gmail.com Fri Aug 29 18:15:20 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 30 Aug 2008 02:15:20 +1000 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> <20080829042146.6DC123A408D@sparrow.telecommunity.com> <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> Message-ID: <48B82098.8090106@gmail.com> Michele Simionato wrote: > OTOH, for what concerns multiple inheritance, I am still not > convinced it is really worth it. I mean, the MRO is beautiful, > elegant and all that on paper, but on real-life code things as different, > especially from the side of the users of frameworks heavily > based on inheritance. The mixin methods in the ABC machinery would be a lot less useful without multiple inheritance (and the collections ABCs would be a whole lot harder to define and to write). So if you're looking for use cases for multiple inheritance, I'd suggest starting with the Python 2.6 collections module and seeing how you would go about rewriting it using only single inheritance. I believe the new io module is also fairly dependent on multiple inheritance. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From michele.simionato at gmail.com Fri Aug 29 19:46:36 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Fri, 29 Aug 2008 19:46:36 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <48B82098.8090106@gmail.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> <20080829042146.6DC123A408D@sparrow.telecommunity.com> <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> <48B82098.8090106@gmail.com> Message-ID: <4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com> On Fri, Aug 29, 2008 at 6:15 PM, Nick Coghlan wrote: > The mixin methods in the ABC machinery would be a lot less useful > without multiple inheritance (and the collections ABCs would be a whole > lot harder to define and to write). > > So if you're looking for use cases for multiple inheritance, I'd suggest > starting with the Python 2.6 collections module and seeing how you would > go about rewriting it using only single inheritance. I believe the new > io module is also fairly dependent on multiple inheritance. I am very well aware of the collection module and the ABC mechanism. However, you are missing that mixins can be implemented in a single-inheritance world without the complications of the MRO. See my answer to Alex Martelli in this same thread. From casey at pandora.com Fri Aug 29 20:33:35 2008 From: casey at pandora.com (Casey Duncan) Date: Fri, 29 Aug 2008 12:33:35 -0600 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> <20080829042146.6DC123A408D@sparrow.telecommunity.com> <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> <48B82098.8090106@gmail.com> <4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com> Message-ID: <5A0A8180-273D-4739-869C-8F5A35184FC5@pandora.com> On Aug 29, 2008, at 11:46 AM, Michele Simionato wrote: > On Fri, Aug 29, 2008 at 6:15 PM, Nick Coghlan > wrote: >> The mixin methods in the ABC machinery would be a lot less useful >> without multiple inheritance (and the collections ABCs would be a >> whole >> lot harder to define and to write). >> >> So if you're looking for use cases for multiple inheritance, I'd >> suggest >> starting with the Python 2.6 collections module and seeing how you >> would >> go about rewriting it using only single inheritance. I believe the >> new >> io module is also fairly dependent on multiple inheritance. > > I am very well aware of the collection module and the ABC mechanism. > However, you are missing that mixins can be implemented in a single- > inheritance > world without the complications of the MRO. See my answer to Alex > Martelli in this same thread. As interesting as this conversation is at a meta-level, I'm not sure how much more can be accomplished here by debating the merits of multiple vs. single inheritance. Unfortunately I think this is a case where there is not just one good way to do it in all cases, especially given the subjective nature of "good" in this context. This is what I take away from this: - super() is tricky to use at best, and its documentation is inaccurate and incomplete. I think it should also be made more clear that super() is really mostly useful for framework developers, including users extending frameworks. Unfortunately many frameworks require you to extend them in order to write useful applications in my experience, so it trickles down to the app developer at times. In short, more correct documentation == good. - The difficulties of super() are really symptomatic of the difficulties of multiple inheritance. I think it's clear that multiple inheritance is here to stay in Python, and it solves certain classes of problems quite well. But, it requires careful consideration, and it's easy to get carried away and create a huge mess (ala Zope2, which I am all too familiar), and it can hinder code clarity as much as it facilitates reuse. - There are good alternatives to multiple inheritance for many cases, but there are cases where multiple inheritance is arguably best. Traits are a possible alternative that deserve further study. I think that study would be greatly aided by a 3rd-party library implementing traits for Python. If traits are to gain any traction or ever be considered for inclusion into the language such a library would need to exist first and demonstrate its utility. I know I'm probably just stating the obvious here, but I found it therapeutic ;^) -Casey From glyph at divmod.com Fri Aug 29 22:31:07 2008 From: glyph at divmod.com (glyph at divmod.com) Date: Fri, 29 Aug 2008 20:31:07 -0000 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <5A0A8180-273D-4739-869C-8F5A35184FC5@pandora.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> <20080829042146.6DC123A408D@sparrow.telecommunity.com> <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> <48B82098.8090106@gmail.com> <4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com> <5A0A8180-273D-4739-869C-8F5A35184FC5@pandora.com> Message-ID: <20080829203107.25821.320776057.divmod.xquotient.15101@joule.divmod.com> On 06:33 pm, casey at pandora.com wrote: >On Aug 29, 2008, at 11:46 AM, Michele Simionato wrote: >>On Fri, Aug 29, 2008 at 6:15 PM, Nick Coghlan >>wrote: >>I am very well aware of the collection module and the ABC mechanism. >>However, you are missing that mixins can be implemented in a single- >>inheritance >>world without the complications of the MRO. See my answer to Alex >>Martelli in this same thread. >- super() is tricky to use at best, and its documentation is >inaccurate and incomplete. I think it should also be made more clear >that super() is really mostly useful for framework developers, >including users extending frameworks. Unfortunately many frameworks >require you to extend them in order to write useful applications in my >experience, so it trickles down to the app developer at times. In >short, more correct documentation == good. >I know I'm probably just stating the obvious here, but I found it >therapeutic ;^) I think this is a problem with this topic. Everyone writing about super() seems to be not just clearing up the documentation issues that surround it, but venting from personal frustrations with using it as well. I confess that I have done the same - if not in widely-publicized articles, at least on IRC and mailing list posts. I think it would benefit everyone if this discussion would end up with some patches to the library documentation that documented the semantics of super() more completely in the reference documentation and the "multiple inheritance" area of the tutorial, so that when people *do* run in to difficulties there is a very clear, central explanation of what it's supposed to do. Personally I think the thing that really should be pointed out is that it may behave in a confusing manner if the signature of the method being invoked is not the same on all classes in the same inheritance hierarchy. Theoretical problems aside, 99% of the trouble I've had with super() has to do with __init__ methods. I'll try my hand at such a patch over the weekend, but I'd be grateful for some pointers on a "quick start" for that. I am a complete newb at modifying the official documentation, and I seem to recall from a prior (failed) attempt that the tools are a bit difficult to work with. From python at rcn.com Fri Aug 29 22:39:39 2008 From: python at rcn.com (Raymond Hettinger) Date: Fri, 29 Aug 2008 13:39:39 -0700 Subject: [Python-Dev] Things to Know About Super References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com><20080828152941.CD4E43A410E@sparrow.telecommunity.com><4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com><20080828185312.943163A408D@sparrow.telecommunity.com><4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com><20080829042146.6DC123A408D@sparrow.telecommunity.com><4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com><48B82098.8090106@gmail.com><4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com><5A0A8180-273D-4739-869C-8F5A35184FC5@pandora.com> <20080829203107.25821.320776057.divmod.xquotient.15101@joule.divmod.com> Message-ID: <23438612C5C6482F89B23B262ECE4259@RaymondLaptop1> From: > I think it would benefit everyone if this discussion would end up with > some patches to the library documentation that documented the semantics > of super() more completely in the reference documentation and the > "multiple inheritance" area of the tutorial, so that when people *do* > run in to difficulties there is a very clear, central explanation of > what it's supposed to do. Am working on a doc patch, will post this weekend. Raymond From michele.simionato at gmail.com Sat Aug 30 06:16:15 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Sat, 30 Aug 2008 06:16:15 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <5A0A8180-273D-4739-869C-8F5A35184FC5@pandora.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> <20080829042146.6DC123A408D@sparrow.telecommunity.com> <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> <48B82098.8090106@gmail.com> <4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com> <5A0A8180-273D-4739-869C-8F5A35184FC5@pandora.com> Message-ID: <4edc17eb0808292116q39763348g162b8f90787e8e6c@mail.gmail.com> On Fri, Aug 29, 2008 at 8:33 PM, Casey Duncan wrote: > - There are good alternatives to multiple inheritance for many cases, but > there are cases where multiple inheritance is arguably best. Maybe, but I am still biased in the opposite direction ;) >Traits are a > possible alternative that deserve further study. I think that study would be > greatly aided by a 3rd-party library implementing traits for Python. If > traits are to gain any traction or ever be considered for inclusion into the > language such a library would need to exist first and demonstrate its > utility. I wrote a trait library which I plan to release soon or later. However it is intended as a proof of concept, not as a candidate for inclusion in the standard library. As of now, I don't think we should have a different way of doing mixins in the standard library. There should be only one obvious way and the obvious way in current Python is multiple inheritance as it is now. The proof of concept is important for educational purposes, to open the mind to alternatives, to give inspiration to the creators of new languages: it is not intended to add complication (whenever small) to current Python. Having said that, maybe once I release the library people will start using it in production and will ask for inclusion for the standard library, but this is not my goal now. This happened for my decorator module years ago: when I wrote it I did not expect people to use it, I saw it as a temporary hack until we got a better support for fiddling with function signatures in the standard library. Nevertheless now a lot of people are using it and I am not even sure it is a good thing (I have seen many decorator abuses out there). This the strange thing that happens when you release a library: you will never now what people will end up using it for ;) Michele Simionato From michal at yogi.htu.tuwien.ac.at Sat Aug 30 12:04:41 2008 From: michal at yogi.htu.tuwien.ac.at (Michal Revucky) Date: Sat, 30 Aug 2008 12:04:41 +0200 Subject: [Python-Dev] script containing all opcs Message-ID: <20080830100441.GC29943@yogi> hello everyone, i would like to get a python script which executes all interpreter's opcodes, or how am i supposed to create such script... i just need to make sure that all opcodes (as defined in Include/opcode.h) are executed by this scrip i need this script for testing purposes while rewritting the python's ceval.c code... bye michal From g.brandl at gmx.net Sat Aug 30 15:15:09 2008 From: g.brandl at gmx.net (Georg Brandl) Date: Sat, 30 Aug 2008 15:15:09 +0200 Subject: [Python-Dev] script containing all opcs In-Reply-To: <20080830100441.GC29943@yogi> References: <20080830100441.GC29943@yogi> Message-ID: Michal Revucky schrieb: > hello everyone, > > i would like to get a python script which executes all interpreter's opcodes, or > how am i supposed to create such script... i just need to make sure that all > opcodes (as defined in Include/opcode.h) are executed by this scrip > i need this script for testing purposes while rewritting the python's ceval.c > code... This question might better suit comp.lang.python, but nevertheless: The opcodes are quite well documented, in the documentation of the "dis" module. Many of them serve a specific purpose (like implementing `x[y]` or `raise x`) and should therefore be easy to test. For the others, like ROT_TWO, you'll need to look into Python/compile.c to find out in which cases they are generated. 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. From ondrej at certik.cz Sat Aug 30 20:41:30 2008 From: ondrej at certik.cz (Ondrej Certik) Date: Sat, 30 Aug 2008 20:41:30 +0200 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B81E24.2070906@gmail.com> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7DBD8.8070205@voidspace.org.uk> <48B81E24.2070906@gmail.com> Message-ID: <85b5c3130808301141t4f2b24d8ybd544de0f26d7f4c@mail.gmail.com> > I strongly advise people interested in this topic to take a closer look > at the functionality that was added to address issue 2235. The "don't > inherit __hash__" behaviour has been backported from 3.0 and broke a > bunch of code, but the naive fix of reverting to the 2.5 behaviour > proceeded to make the 2.6 version of collections.Hashable completely > useless (since pretty much *everything* then claimed to be hashable, > including all of the container types in the standard library). > > After thrashing out those problems, the 2.6 behaviour ended up being: > - __hash__ is still inherited by default > - you can block inheritance explicitly by setting "__hash__ = None" in > the class definition or on the class object > - for a class defined in C, you can block __hash__ inheritance by > setting the tp_hash slot to PyObject_HashNotImplemented > - using one of the above approaches will cause hash(obj) to raise a > TypeError, as will calling the tp_hash slot directly > - unlike defining your own __hash__ method, using one of the above > techniques will also mean that isinstance(obj, collections.Hashable) > will also return False > - defining __eq__ and/or __cmp__ without defining __hash__ will lead to > a Py3k Warning being raised on the class definition when run with the -3 > switch > > The Python 3.0 behaviour is similar to the above, except that the > unconditional inheritance of __hash__ is gone. If you define __eq__ or > __cmp__ without defining __hash__, __hash__ will NOT be inherited from > the parent class - instead, it will be set to None. > > The documentation of all of this could definitely use a bit more work - > that's why I reopened 2235 in response to Michael's post. Couple months ago I was trying to figure out how __eq__, __cmp__, __hash__ and similar methods are called in Python and in which order and wrote a docs here: http://docs.sympy.org/python-comparisons.html Feel free to reuse any of it. I wrote it to myself, as I didn't find the official docs very clear. Ondrej From jnoller at gmail.com Sat Aug 30 21:13:32 2008 From: jnoller at gmail.com (Jesse Noller) Date: Sat, 30 Aug 2008 15:13:32 -0400 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <85b5c3130808301141t4f2b24d8ybd544de0f26d7f4c@mail.gmail.com> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7DBD8.8070205@voidspace.org.uk> <48B81E24.2070906@gmail.com> <85b5c3130808301141t4f2b24d8ybd544de0f26d7f4c@mail.gmail.com> Message-ID: <9AE6735E-45F6-4A66-B749-1DB7A3D39EA3@gmail.com> On Aug 30, 2008, at 2:41 PM, "Ondrej Certik" wrote: >> I strongly advise people interested in this topic to take a closer >> look >> at the functionality that was added to address issue 2235. The "don't >> inherit __hash__" behaviour has been backported from 3.0 and broke a >> bunch of code, but the naive fix of reverting to the 2.5 behaviour >> proceeded to make the 2.6 version of collections.Hashable completely >> useless (since pretty much *everything* then claimed to be hashable, >> including all of the container types in the standard library). >> >> After thrashing out those problems, the 2.6 behaviour ended up being: >> - __hash__ is still inherited by default >> - you can block inheritance explicitly by setting "__hash__ = None" >> in >> the class definition or on the class object >> - for a class defined in C, you can block __hash__ inheritance by >> setting the tp_hash slot to PyObject_HashNotImplemented >> - using one of the above approaches will cause hash(obj) to raise a >> TypeError, as will calling the tp_hash slot directly >> - unlike defining your own __hash__ method, using one of the above >> techniques will also mean that isinstance(obj, collections.Hashable) >> will also return False >> - defining __eq__ and/or __cmp__ without defining __hash__ will >> lead to >> a Py3k Warning being raised on the class definition when run with >> the -3 >> switch >> >> The Python 3.0 behaviour is similar to the above, except that the >> unconditional inheritance of __hash__ is gone. If you define __eq__ >> or >> __cmp__ without defining __hash__, __hash__ will NOT be inherited >> from >> the parent class - instead, it will be set to None. >> >> The documentation of all of this could definitely use a bit more >> work - >> that's why I reopened 2235 in response to Michael's post. > > Couple months ago I was trying to figure out how __eq__, __cmp__, > __hash__ and similar methods are called in Python and in which order > and wrote a docs here: > > http://docs.sympy.org/python-comparisons.html > > Feel free to reuse any of it. I wrote it to myself, as I didn't find > the official docs very clear. > > Ondrej Ondrej, a patch that improves the official docs would be welcome and still potentially make 2.6/3.0 From ondrej at certik.cz Sat Aug 30 21:35:21 2008 From: ondrej at certik.cz (Ondrej Certik) Date: Sat, 30 Aug 2008 21:35:21 +0200 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <9AE6735E-45F6-4A66-B749-1DB7A3D39EA3@gmail.com> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7DBD8.8070205@voidspace.org.uk> <48B81E24.2070906@gmail.com> <85b5c3130808301141t4f2b24d8ybd544de0f26d7f4c@mail.gmail.com> <9AE6735E-45F6-4A66-B749-1DB7A3D39EA3@gmail.com> Message-ID: <85b5c3130808301235t7ce79662t767c2831e736d808@mail.gmail.com> >> Ondrej > > Ondrej, a patch that improves the official docs would be welcome and still > potentially make 2.6/3.0 That'd be awesome. I need to finish my thesis in the next couple days, so I'd welcome if anyone could just take it and put usefult things in. I could get to do it the next week the earliest. Ondrej From solipsis at pitrou.net Sat Aug 30 22:06:00 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 30 Aug 2008 20:06:00 +0000 (UTC) Subject: [Python-Dev] The recursion checking problem Message-ID: Hi, I was working on a recursion overflow checking bug (http://bugs.python.org/issue2548) and, while I've managed to produce a working patch, I've also become uncomfortable with the very idea of trying to plug all those holes just for the sake of plugging them. I'll try to explain why, by describing the conflicting factors I've identified: - more and more, we are adding calls to Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() all over the interpreter, to avoid special/obscure cases of undetected infinite recursion; this can probably be considered a good thing, but: - after a recursion error has been raised (technically a RuntimeError), usually some code has to do cleanup after noticing the exception; this cleanup now can very easily bump into the recursion limit again, due to the point mentioned above (the funniest example of this is PyErr_ExceptionMatches, which makes a call to PyObject_IsSubclass which itself increases the recursion count because __subclasscheck__ can be recursively invoked...). - to counter the latter problem, py3k has introduced a somewhat smarter mechanism (which I've tracked down to a commit in the defunct p3yk branch by Martin): when the recursion limit is exceeded, a special flag named "overflowed" is set in the thread state structure which disables the primary recursion check, so that cleanup code has a bit of room to increase the recursion count a bit. A secondary recursion check exists (equal to the primary one /plus/ 50) and, if it is reached, the interpreter aborts with a fatal error. The "overflowed" flag is cleared when the recursion count drops below the primary recursion limit /minus/ 50. Now it looks rather smart but: - unfortunately, some functions inside the interpreter discard every exception by design. The primary example is PyDict_GetItem(), which is certainly used quite a lot :-)... When PyDict_GetItem() returns NULL, the caller can only assume that the key isn't in the dict, it has no way to know that there was a critical problem due to a recursion overflow. I encountered the latter problem when trying to backport the py3k recursion overflow algorithm to trunk. A fatal error suddenly appeared in test_cpickle, and it turned out that the recursion count was exceeded in PyObject_RichCompare(), the error was then cleared in PyDict_GetItem(), but the "overflowed" flag was still set so that a subsequent recursion overflow would trigger the secondary check and lead to the fatal error. I guess that, if it doesn't happen in py3k, it's just by chance: the recursion overflow is probably happening at another point where errors don't get discarded. Indeed, the failure I got on trunk was manifesting itself when running "regrtest.py test_cpickle" but not directly "test_cpickle.py"... which shows how delicate the recursion mechanism has become. My attempt to solve the latter problem while still backporting the py3k scheme involves clearing the "overflowed" flag in PyErr_Clear(). This makes all tests pass ok, but also means the "overflowed" flag loses a lot of its meaning... since PyErr_Clear() is called in a lot of places (and, especially, in PyDict_GetItem()). Also, at this point I fear that the solution to the problem is becoming, because of its complexity, perhaps worse than the problem itself. That's why I'm bringing it here, to have your opinion. (I also suggest that we stop trying to fix recursion checking bugs until the stable release, so as to give us some time to do the Right Thing later - if there is such a thing) Regards Antoine. From brett at python.org Sat Aug 30 22:29:12 2008 From: brett at python.org (Brett Cannon) Date: Sat, 30 Aug 2008 13:29:12 -0700 Subject: [Python-Dev] The recursion checking problem In-Reply-To: References: Message-ID: On Sat, Aug 30, 2008 at 1:06 PM, Antoine Pitrou wrote: > > Hi, > > I was working on a recursion overflow checking bug > (http://bugs.python.org/issue2548) and, while I've managed to produce a working > patch, I've also become uncomfortable with the very idea of trying to plug all > those holes just for the sake of plugging them. I'll try to explain why, by > describing the conflicting factors I've identified: > > - more and more, we are adding calls to Py_EnterRecursiveCall() and > Py_LeaveRecursiveCall() all over the interpreter, to avoid special/obscure > cases of undetected infinite recursion; this can probably be considered a good > thing, but: > > - after a recursion error has been raised (technically a RuntimeError), usually > some code has to do cleanup after noticing the exception; this cleanup now can > very easily bump into the recursion limit again, due to the point mentioned > above (the funniest example of this is PyErr_ExceptionMatches, which makes a > call to PyObject_IsSubclass which itself increases the recursion count because > __subclasscheck__ can be recursively invoked...). > > - to counter the latter problem, py3k has introduced a somewhat smarter > mechanism (which I've tracked down to a commit in the defunct p3yk branch by > Martin): when the recursion limit is exceeded, a special flag named > "overflowed" is set in the thread state structure which disables the primary > recursion check, so that cleanup code has a bit of room to increase the > recursion count a bit. A secondary recursion check exists (equal to the primary > one /plus/ 50) and, if it is reached, the interpreter aborts with a fatal error. > The "overflowed" flag is cleared when the recursion count drops below the > primary recursion limit /minus/ 50. Now it looks rather smart but: > > - unfortunately, some functions inside the interpreter discard every exception > by design. The primary example is PyDict_GetItem(), which is certainly used > quite a lot :-)... When PyDict_GetItem() returns NULL, the caller can only > assume that the key isn't in the dict, it has no way to know that there was a > critical problem due to a recursion overflow. > As the comment says for PyDict_GetItem(), it's a relic from the days when there was no way to call Python code when making the call. That is no longer true (and is probably true for a lot of places where a similar assumption is made). > I encountered the latter problem when trying to backport the py3k recursion > overflow algorithm to trunk. A fatal error suddenly appeared in test_cpickle, > and it turned out that the recursion count was exceeded in > PyObject_RichCompare(), the error was then cleared in PyDict_GetItem(), but the > "overflowed" flag was still set so that a subsequent recursion overflow would > trigger the secondary check and lead to the fatal error. > > I guess that, if it doesn't happen in py3k, it's just by chance: the recursion > overflow is probably happening at another point where errors don't get > discarded. Indeed, the failure I got on trunk was manifesting itself when > running "regrtest.py test_cpickle" but not directly "test_cpickle.py"... which > shows how delicate the recursion mechanism has become. > > My attempt to solve the latter problem while still backporting the py3k scheme > involves clearing the "overflowed" flag in PyErr_Clear(). This makes all tests > pass ok, but also means the "overflowed" flag loses a lot of its meaning... > since PyErr_Clear() is called in a lot of places (and, especially, in > PyDict_GetItem()). > > > Also, at this point I fear that the solution to the problem is becoming, > because of its complexity, perhaps worse than the problem itself. That's why > I'm bringing it here, to have your opinion. > Well, For Py3K at least we might need to consider going through the C API and fixing it so that these incorrect assumptions that functions like PyDict_GetItem() make are no longer made by introducing some new functions that behave in a "better" way. And for the recursion issue, I think it stems from corners that are cut in the C API by us. We inline functions all over the place, assume that Python's implementation underneath the hood is going to make calls that stay in C, etc. But as time has gone on and we have added flexibility to Python, more and more places have a chance to call Python code and trigger issues. > (I also suggest that we stop trying to fix recursion checking bugs until the > stable release, so as to give us some time to do the Right Thing later - if > there is such a thing) > I have no problem punting for now; there is no way I would be willing to wager any amount of money that the recursion check covered all cases. I have always viewed the check as a bonus sanity check, but not something to heavily rely upon. -Brett From stephane at harobed.org Sat Aug 30 22:30:54 2008 From: stephane at harobed.org (=?iso-8859-1?q?KLEIN_St=E9phane?=) Date: Sat, 30 Aug 2008 20:30:54 +0000 (UTC) Subject: [Python-Dev] [optparse] I wonder if optparse is dead ? because... Message-ID: Hello, I wonder if optparse is dead ? because : * svn access is down (svn co svn://starship.python.net/optik/trunk optik) ( http://sourceforge.net/mailarchive/forum.php? thread_name=466F541C.6010804%40users.sourceforge.net&forum_name=optik- users ) * last release is out 2 years ago ( http://sourceforge.net/mailarchive/forum.php? thread_name=20060723161651.GA2076%40cthulhu.gerg.ca&forum_name=optik- users ) * Greg Ward mail ( gward at python.net ) and is home page (http:// www.gerg.ca/) are away * I'm interested by this feature http://sourceforge.net/tracker/index.php? func=detail&aid=1819510&group_id=38019&atid=421097 but it hasn't comment since one year ago. Otherwise optparse is a great module ! Thanks for your information, Stephane From g.brandl at gmx.net Sat Aug 30 23:09:05 2008 From: g.brandl at gmx.net (Georg Brandl) Date: Sat, 30 Aug 2008 23:09:05 +0200 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <85b5c3130808301235t7ce79662t767c2831e736d808@mail.gmail.com> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7DBD8.8070205@voidspace.org.uk> <48B81E24.2070906@gmail.com> <85b5c3130808301141t4f2b24d8ybd544de0f26d7f4c@mail.gmail.com> <9AE6735E-45F6-4A66-B749-1DB7A3D39EA3@gmail.com> <85b5c3130808301235t7ce79662t767c2831e736d808@mail.gmail.com> Message-ID: Ondrej Certik schrieb: >>> Ondrej >> >> Ondrej, a patch that improves the official docs would be welcome and still >> potentially make 2.6/3.0 > > That'd be awesome. I need to finish my thesis in the next couple days, > so I'd welcome if anyone could just take it and put usefult things in. > I could get to do it the next week the earliest. Doc patches are always accepted, and I intend to update the online 2.6 and 3.0 docs continually even when the finals are released, so there is no particular deadline you have to make. 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. From g.brandl at gmx.net Sat Aug 30 23:11:21 2008 From: g.brandl at gmx.net (Georg Brandl) Date: Sat, 30 Aug 2008 23:11:21 +0200 Subject: [Python-Dev] [optparse] I wonder if optparse is dead ? because... In-Reply-To: References: Message-ID: KLEIN St?phane schrieb: > Hello, > > I wonder if optparse is dead ? because : > > * svn access is down (svn co svn://starship.python.net/optik/trunk optik) > ( http://sourceforge.net/mailarchive/forum.php? > thread_name=466F541C.6010804%40users.sourceforge.net&forum_name=optik- > users ) > > * last release is out 2 years ago > ( http://sourceforge.net/mailarchive/forum.php? > thread_name=20060723161651.GA2076%40cthulhu.gerg.ca&forum_name=optik- > users ) > > * Greg Ward mail ( gward at python.net ) and is home page (http:// > www.gerg.ca/) are away > > * I'm interested by this feature > http://sourceforge.net/tracker/index.php? > func=detail&aid=1819510&group_id=38019&atid=421097 > but it hasn't comment since one year ago. > > Otherwise optparse is a great module ! Well, the module itself certainly isn't dead since it's distributed with Python. What might be dead is the standalone version, Optik. However, we have so far delegated feature requests to Greg and expected them to be included in Optik first before being merged to the core. If Optik is no longer maintained, we can do this directly in the core, with Python's release cycle. 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. From ziade.tarek at gmail.com Sat Aug 30 23:15:13 2008 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Sat, 30 Aug 2008 23:15:13 +0200 Subject: [Python-Dev] [optparse] I wonder if optparse is dead ? because... In-Reply-To: References: Message-ID: <94bdd2610808301415laaf9e01rc0a8637f90b17f3d@mail.gmail.com> On Sat, Aug 30, 2008 at 10:30 PM, KLEIN St?phane wrote: > Hello, > > I wonder if optparse is dead ? because : > > * svn access is down (svn co svn://starship.python.net/optik/trunk optik) > ( http://sourceforge.net/mailarchive/forum.php? > thread_name=466F541C.6010804%40users.sourceforge.net&forum_name=optik- > users ) > > * last release is out 2 years ago > ( http://sourceforge.net/mailarchive/forum.php? > thread_name=20060723161651.GA2076%40cthulhu.gerg.ca&forum_name=optik- > users ) > Hello, It has been integrated in Python since then, afaik http://svn.python.org/projects/python/trunk/Lib/optparse.py > > * Greg Ward mail ( gward at python.net ) and is home page (http:// > www.gerg.ca/) are away > > * I'm interested by this feature > http://sourceforge.net/tracker/index.php? > func=detail&aid=1819510&group_id=38019&atid=421097 > but it hasn't comment since one year ago. > > Otherwise optparse is a great module ! > > Thanks for your information, > Stephane > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com > -- Tarek Ziad? | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej at certik.cz Sat Aug 30 23:24:45 2008 From: ondrej at certik.cz (Ondrej Certik) Date: Sat, 30 Aug 2008 23:24:45 +0200 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7DBD8.8070205@voidspace.org.uk> <48B81E24.2070906@gmail.com> <85b5c3130808301141t4f2b24d8ybd544de0f26d7f4c@mail.gmail.com> <9AE6735E-45F6-4A66-B749-1DB7A3D39EA3@gmail.com> <85b5c3130808301235t7ce79662t767c2831e736d808@mail.gmail.com> Message-ID: <85b5c3130808301424j5da8308fg212e2a06b84d5981@mail.gmail.com> Hi Georg! On Sat, Aug 30, 2008 at 11:09 PM, Georg Brandl wrote: > Ondrej Certik schrieb: >>>> Ondrej >>> >>> Ondrej, a patch that improves the official docs would be welcome and still >>> potentially make 2.6/3.0 >> >> That'd be awesome. I need to finish my thesis in the next couple days, >> so I'd welcome if anyone could just take it and put usefult things in. >> I could get to do it the next week the earliest. > > Doc patches are always accepted, and I intend to update the online 2.6 and > 3.0 docs continually even when the finals are released, so there is no > particular deadline you have to make. This is awesome, I didn't know you take care of the official docs too. I'll send the doc patches when I get to it, unless someone else does it before me. Ondrej From stephane at harobed.org Sat Aug 30 23:29:19 2008 From: stephane at harobed.org (=?iso-8859-1?q?KLEIN_St=E9phane?=) Date: Sat, 30 Aug 2008 21:29:19 +0000 (UTC) Subject: [Python-Dev] [optparse] I wonder if optparse is dead ? because... References: <94bdd2610808301415laaf9e01rc0a8637f90b17f3d@mail.gmail.com> Message-ID: Le Sat, 30 Aug 2008 23:15:13 +0200, Tarek Ziad? a ?crit?: > On Sat, Aug 30, 2008 at 10:30 PM, KLEIN St?phane > wrote: > >> Hello, >> >> I wonder if optparse is dead ? because : >> >> * svn access is down (svn co svn://starship.python.net/optik/trunk >> optik) ( http://sourceforge.net/mailarchive/forum.php? >> thread_name=466F541C.6010804%40users.sourceforge.net&forum_name=optik- >> users ) >> >> * last release is out 2 years ago >> ( http://sourceforge.net/mailarchive/forum.php? >> thread_name=20060723161651.GA2076%40cthulhu.gerg.ca&forum_name=optik- >> users ) >> >> > Hello, > > It has been integrated in Python since then, afaik > > http://svn.python.org/projects/python/trunk/Lib/optparse.py > Yes, I know but there are this lines in optparse.py source code : """ By Greg Ward Originally distributed as Optik; see http://optik.sourceforge.net/ . If you have problems with this module, please do not file bugs, patches, or feature requests with Python; instead, use Optik's SourceForge project page: http://sourceforge.net/projects/optik For support, use the optik-users at lists.sourceforge.net mailing list (http://lists.sourceforge.net/lists/listinfo/optik-users). """ then if I read this, I need to send my request feature to Optik web site but it appear asleep. Regards, Stephane From michele.simionato at gmail.com Sun Aug 31 09:12:27 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Sun, 31 Aug 2008 09:12:27 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808292116q39763348g162b8f90787e8e6c@mail.gmail.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> <20080829042146.6DC123A408D@sparrow.telecommunity.com> <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> <48B82098.8090106@gmail.com> <4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com> <5A0A8180-273D-4739-869C-8F5A35184FC5@pandora.com> <4edc17eb0808292116q39763348g162b8f90787e8e6c@mail.gmail.com> Message-ID: <4edc17eb0808310012w4cd0f340u70f3664aa938be6d@mail.gmail.com> On Sat, Aug 30, 2008 at 6:16 AM, Michele Simionato > I wrote a trait library which I plan to release soon or later. Ok, just for the people here that cannot wait I have prepared a pre-alpha snapshot and uploaded it to my site: http://www.phyast.pitt.edu/~micheles/python/strait.html At some moment I want to release it officially, but as of now I do not feel I have nailed out all the details and there may be difficulties I have not foreseen. If it is so, I am sure Phillip will find out all the loopholes ;) Nevertheless, I feel that I have covered out a lot of use cases that I cared to cover, and that there is something good in there, so have fun with this foolish attempt of putting multiple inheritance straight! ;-) Michele Simionato From jcea at jcea.es Sun Aug 31 16:43:34 2008 From: jcea at jcea.es (Jesus Cea) Date: Sun, 31 Aug 2008 16:43:34 +0200 Subject: [Python-Dev] Email update Message-ID: <48BAAE16.9010200@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm getting some private email about python issues in "jcea at argo.es". This email address works for now, but it is "deprecated". My current email is "jcea at jcea.es". Please, update your addressbooks, and any list/contact info out there. I already updated my mailman subscriptions months ago. My old email can vanish without warning. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSLquCZlgi5GaxT1NAQKQRwP/fI7xR3O87aPRSunGIibVqLEAwiSczc8N diWZ2QxSmr2GnL7tDWXU9B/ROxuFL3Rhti21T/BfLDDPn5pi9YmwVkKji4Jt+v1L UROgaJ5nnv1CBiLvKPDSkIoHoFKa4Gx1hIWihEy6Oed8mA8qKP+rm0tX0NfWJaRo ofEja3FooDs= =wYIM -----END PGP SIGNATURE-----

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4