Mailman 3 March 2006 - Python-Dev

gmane.comp.python.devel.3000 has disappeared
by Terry Reedy April 1, 2006

April 1, 2006

For about a week, I have been reading and occasionally posting to the new pydev-3000 mailing list via the gmane mirror gmane.comp.lang.devel.3000. Today, it has disappeared and was still gone after reloading their newsgroup list. Was this intentional on the part of the mail list maintainers? (I certainly hope not!) Or is it a repairable glitch somewhere between the list and gmane? Terry Jan Reedy

5 6

Name for python package repository
by Greg Ewing April 1, 2006

April 1, 2006

I just thought of a possible name for the Python package repository. We could call it the PIPE - Python Index of Packages and Extensions. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing(a)canterbury.ac.nz +--------------------------------------+

2 1

reference leaks, __del__, and annotations
by Jim Jewett April 1, 2006

April 1, 2006

Duncan Booth wrote: > Surely if you have a cycle what you want to do is to pick just *one* of the > objects in the cycle and break the link which makes it participate in the > cycle. No, I really meant to do them all. I was trying to avoid creating an attractive nuisance. In http://mail.python.org/pipermail/python-dev/2006-March/063239.html, Thomas Wouters categorized the purpose of __del__ methods as [paraphrased] (A) Resource Cleanup (cycles irrelevant) (B) Object created a cycle, and knows how to break it safely. (C) Those which do things the style guide warns against. The catch is that objects in the first two categories have no way to know when they should do the cleanup, except by creating a __del__ method (as generators now do). For category (A), their __del__ methods should be called as early as possible. Even for category (B), it does no harm. Why waste time recalculating cycles more often than required? If the object is lying about whether it can be used to safely break cycles, that is a bug, and I would rather catch it as early as possible, instead of letting it hide behind "oh well, the cycle was already broken". In fairness, I had not fully considered category(C), when an object intends not only to revive itself, but to prevent its subobjects from cleaning up either. Nick Coghlan > A simple Boolean attribute (e.g. __finalized__) should be enough. ... > If it's both present and true, the GC can ignore the finaliser on that instance That doesn't really take care of resource release, which needs to be called, and called early.(And the name will sound odd if it holds resources only sometimes, so that it has to flip the __finalized__ attribute.) -jJ

2 2

Class decorators
by Jim Jewett April 1, 2006

April 1, 2006

Nick Coghlan wrote: > [ much good, including the @instance decorator ] > P.S. If all you want is somewhere to store mutable > state between invocations, you can always use the > function's own attribute space >>> def f(): print "Hi world from %s!" % f >>> f() Hi world from <function f at 0x00AE90B0>! Not really. That assumes the expected name is (permanently) bound to *this* function in this function's globals. That's normally true, but not always, so relying on it seems wrong. >>> f="a string" >>> g() Hi world from a string! And of course, sometimes I really do want shared state, or helpers (like other methods on a class), or one-time ininitialization plus per-call parameters (like the send method on 2.5 generators), or ... -jJ

2 1

Re: [Python-Dev] Class decorators
by Phillip J. Eby March 31, 2006

March 31, 2006

At 04:47 AM 3/31/2006 -0800, Michael Chermside wrote: >In the discussion over class decorators, Jim Jewett writes: > > I have often started with a function, and ended up replacing it with a > > callable object so that I could save state without resorting to > > "defalt args" or worse. > > > > I would prefer to decorate these exactly like the functions they replace. > >I have observed the entire discussion about class decorators with absolutely >no opinion, until I read Jim's brief post quoted above. I am now completely >convinced that class decorators ought to exist and behave exactly like >function decorators. Thanks, Jim for pointing out what should have been >obvious to me from the start. The ability to use callable objects as >functions is a powerful tool in Python, and ought not be broken by decorator >inconsistencies. Unless the class has a metaclass implementing __call__, or you mean that you want instance creation to be a call, I don't understand what you mean. Nonetheless, the discussion has only been about *where* the decorators go and what syntax they use. Nobody has proposed any change in decorator semantics, so please stop attacking this meaningless strawman. Moving from: @foo def bar(...): ... to: class bar: @class foo def __init___(...): ... instead of: @foo class bar: def __init___(...): ... is a trivial difference in editing: you type "class " one more time.

2 1

Re: [Python-Dev] reference leaks, __del__, and annotations
by Phillip J. Eby March 31, 2006

March 31, 2006

At 12:14 PM 3/31/2006 -0500, Tim Peters wrote: >[Phillip J. Eby] > > ... > > As Tim suggested, it'd be better to have the code be generator-specific, at > > least for now. That had actually been my original plan, to make it > > generator-specific, but I was afraid of breaking encapsulation in the > > garbage collector by having it know about generators. > >It sucks in a way, but so would adding yet another new slot just for >(at present, and possibly forever) making gc and generators play nicer >together. "Practicality beats purity" here. > > > But now that Uncle Timmy has blessed the approach, I'll go back and add > it in. > > (On Monday, unless somebody gets to it before me.) > >It won't be me: I wasn't even able to make enough time to understand >the new generator features at the Python level, let alone the >implementation. At PyCon, when Guido showed his slide with a new >yield-as-expression example, for the rest of his talk I was wondering >what the heck the example meant <0.3 wink>. Think of yield as being a sort of IPC operator: it sends a value out of the generator, and then replaces it with a "return value" that defaults to None. On the opposite side of the communication, calling send(value) allows you to put a value "into" the generator, and returns the next value from the generator. The existing next() operation is effectively send(None). So, it's effectively an asymmetric IPC system, using a yield operator and a send() method. On either side, the operation takes a value to give to the other side of the communication, and then returns the value that's passed "back" by the other side. that takes an expression, sends it out of the generator, and then brings back in a "return value" - sort of like sending some kind of IPC message out of the process, and receiving a response.

1 0

Re: [Python-Dev] [Python-checkins] Python Regression Test Failures all (1)
by Jeremy Hylton March 31, 2006

March 31, 2006

On 3/1/06, Neal Norwitz <neal(a)metaslash.com> wrote: > test_bsddb3 > Exception in thread reader 4: > Traceback (most recent call last): > File "/home/neal/python/trunk/Lib/threading.py", line 473, in __bootstrap > self.run() > File "/home/neal/python/trunk/Lib/threading.py", line 453, in run > self.__target(*self.__args, **self.__kwargs) > File "/home/neal/python/trunk/Lib/bsddb/test/test_thread.py", line 275, in readerThread > rec = dbutils.DeadlockWrap(c.next, max_retries=10) > File "/home/neal/python/trunk/Lib/bsddb/dbutils.py", line 62, in DeadlockWrap > return function(*_args, **_kwargs) > DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock') > > Exception in thread writer 0: > Traceback (most recent call last): > File "/home/neal/python/trunk/Lib/threading.py", line 473, in __bootstrap > self.run() > File "/home/neal/python/trunk/Lib/threading.py", line 453, in run > self.__target(*self.__args, **self.__kwargs) > File "/home/neal/python/trunk/Lib/bsddb/test/test_thread.py", line 254, in writerThread > self.assertEqual(data, self.makeData(key)) > File "/home/neal/python/trunk/Lib/unittest.py", line 334, in failUnlessEqual > (msg or '%r != %r' % (first, second)) > AssertionError: None != '0003-0003-0003-0003-0003' > > Exception in thread writer 1: > Traceback (most recent call last): > File "/home/neal/python/trunk/Lib/threading.py", line 473, in __bootstrap > self.run() > File "/home/neal/python/trunk/Lib/threading.py", line 453, in run > self.__target(*self.__args, **self.__kwargs) > File "/home/neal/python/trunk/Lib/bsddb/test/test_thread.py", line 254, in writerThread > self.assertEqual(data, self.makeData(key)) > File "/home/neal/python/trunk/Lib/unittest.py", line 334, in failUnlessEqual > (msg or '%r != %r' % (first, second)) > AssertionError: None != '1000-1000-1000-1000-1000' I haven't run regrtest.py -u all in a while. Are these sorts of errors just tolerated? Jeremy

2 1

x86 trunk MSI preview
by martin＠v.loewis.de March 31, 2006

March 31, 2006

I just created a snapshot MSI release from the trunk (I actually recreated the 25a0 tag for that, to find that subversion will not update $HeadURL$ automatically when switching branches). Please find the file at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13238.msi Regards, Martin

1 0

Re: [Python-Dev] Class decorators
by Michael Chermside March 31, 2006

March 31, 2006

In the discussion over class decorators, Jim Jewett writes: > I have often started with a function, and ended up replacing it with a > callable object so that I could save state without resorting to > "defalt args" or worse. > > I would prefer to decorate these exactly like the functions they replace. I have observed the entire discussion about class decorators with absolutely no opinion, until I read Jim's brief post quoted above. I am now completely convinced that class decorators ought to exist and behave exactly like function decorators. Thanks, Jim for pointing out what should have been obvious to me from the start. The ability to use callable objects as functions is a powerful tool in Python, and ought not be broken by decorator inconsistencies. -- Michael Chermside

2 1

Re: [Python-Dev] [Python-3000] Iterators for dict keys, values, and items == annoying :)
by Nick Coghlan March 31, 2006

March 31, 2006

Paul Moore wrote: > On 3/29/06, Brett Cannon <brett(a)python.org> wrote: >> Without a direct reason in terms of the language needing a >> standardization of an interface, perhaps we just don't need views. If >> people want their iterator to have a __len__ method, then fine, they >> can add it without breaking anything, just realize it isn't part of >> the iterator protocol and thus may limit what objects a function can >> accept, but that is there choice. > > Good point. I think we need to start from strong use cases. With > these, I agree that the view concept is a good implementation > technique to consider. But let's not implement views just for the sake > of having them - I'm pretty sure that was never Guido's intention. There are three big use cases: dict.keys dict.values dict.items Currently these all return lists, which may be expensive in terms of copying. They all have iter* variants which while memory efficient, are far less convenient to work with. For Py3k, the intent is to have only one version which produces a view with the memory efficiency of an iterator, but the convenience of a list. To give these views the benefits of having a real list, the following is all that's really needed: 1. implement __len__ (allows bool() and len() to work) - all delegate to dict.__len__ 2. implement __contains__ (allows containment tests to work) - delegate to dict.__contains__ for dict.keys() - use (or fallback to) linear search for dict.values() - check "dict[item[0]] == item[1]" for dict.items() 3. implement __iter__ (allows iteration to work) - make iter(dict.keys()) equivalent to current dict.iterkeys() - make iter(dict.values()) equivalent to current dict.itervalues() - make iter(dict.items()) equivalent to current dict.iteritems() For an immutable view, that's all you need. IOW, take the iterable protocol (an __iter__ that returns a new iterator when invoked) and add __len__ and __contains__ to get a "container" protocol. Given that containment falls back on __iter__ anyway, __len__ is the only essential addition to turn an iterable into a container. Note that adding __len__ to an *iterator* does NOT give you something that would satisfy such a container protocol - invoking __iter__ again does not give you a fresh iterator, so you can't easily iterate repeatedly. With reiterability as a defining characteristic, other niceties become possible (potentially available as a mixin): 1. a generic container __str__ (not __repr__!) implementation: def __str__(self): # keep default __repr__ since eval(repr(x)) won't round trip name = self.__name__ guts = ", ".join(repr(x) for x in self) return "%s([%s])" % guts 2. generic container value based equality testing: def __eq__(self, other): if len(self) != len(other): return False for this, that in izip(self, other): if this != that: return False return True Further refinement of such a container protocol to the minimal requirements for a sequence protocol is already defined by such things as the requirements of the reversed() builtin: for i, x in enumerate(seq): assert seq[i] == x Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

2 3