Re: [Python-Dev] reference leaks, __del__, and annotations
Jim Jewett [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: As a strawman proposal: deletes = [(obj.__del__.cycle, obj) for obj in cycle if hasattr(obj, __del__) and hasattr(obj.__del__, cycle)] deletes.sort() for (cycle, obj) in deletes: obj.__del__() Lightweight __del__ methods (such as most resource managers) could set the cycle attribute to True, and thereby ensure that they won't cause unbreakable cycles. Fancier object frameworks could use different values for the cycle attribute. Any object whose __del__ is not annotated will still be at least as likely to get finalized as it is That doesn't look right to me. 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. That should be sufficient to cause the rest of the cycle to collapse with __del__ methods being called from the normal refcounting mechanism. So something like this: for obj in cycle: if hasattr(obj, __breakcycle__): obj.__breakcycle__() break Every object which knows it can participate in a cycle then has the option of defining a method which it can use to tear down the cycle. e.g. by releasing the resource and then deleting all of its attributes, but no guarantees are made over which obj has this method called. An object with a __breakcycle__ method would have to be extra careful as its methods could still be called after it has broken the cycle, but it does mean that the responsibilities are in the right place (i.e. defining the method implies taking that into account). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
Martin v. Löwis wrote: Terry Reedy wrote: Gerhard Häring [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I proposed to link dynamically on Windows, and ship the Windows SQLite3.DLL. This has two advantages: - Python users can upgrade the SQLite3.DLL by a simple download from in case of emergency +1 and thanks from a Windows user This binary depends on msvcrt.dll. Does anybody know whether this could cause a problem? IOW, is any of the forbidden API used across the DLL boundary (in particular: memory management, stdio, locales)? AFAIK SQLite does not use stdio or locales. Memory management is normally never done explicitly, but by API calls using opaque pointers to the SQLite structure, for example: - sqlite3_compile will return a SQLite statement. - sqlite3_finalize will clean up the SQLite statement, and return any memory used by it. The only explicit memory management function I know is void sqlite3_free(char *z); which looks ok, too. And pysqlite doesn't use it, anyway. -- Gerhard ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode vs buffer (array) design issue can crash interpreter
Martin v. Löwis wrote:
Neal Norwitz wrote:
See http://python.org/sf/1454485 for the gory details. Basically if
you create a unicode array (array.array('u')) and try to append an
8-bit string (ie, not unicode), you can crash the interpreter.
The problem is that the string is converted without question to a
unicode buffer. Within unicode, it assumes the data to be valid, but
this isn't necessarily the case. We wind up accessing an array with a
negative index and boom.
There are several problems combined here, which might need discussion:
- why does the 'u#' converter use the buffer interface if available?
it should just support Unicode objects. The buffer object makes
no promise that the buffer actually is meaningful UCS-2/UCS-4, so
u# shouldn't guess that it is.
(FWIW, it currently truncates the buffer size to the next-smaller
multiple of sizeof(Py_UNICODE), and silently so)
I think that part should just go: u# should be restricted to unicode
objects.
'u#' is intended to match 's#' which also uses the buffer
interface. It expects the buffer returned by the object
to a be a Py_UNICODE* buffer, hence the calculation of the
length.
However, we already have 'es#' which is a lot safer to use
in this respect: you can explicity define the encoding you
want to see, e.g. 'unicode-internal' and the associated
codec also takes care of range checks, etc.
So, I'm +1 on restricting 'u#' to Unicode objects.
- should Python guarantee that all characters in a Unicode object
are between 0 and sys.maxunicode? Currently, it is possible to
create Unicode strings with either negative or very large Py_UNICODE
elements.
- if the answer to the last question is no (i.e. if it is intentional
that a unicode object can contain arbitrary Py_UNICODE values): should
Python then guarantee that Py_UNICODE is an unsigned type?
Py_UNICODE must always be unsigned. The whole implementation
relies on this and has been designed with this in mind (see
PEP 100). AFAICT, the configure does check that Py_UNICODE
is always unsigned.
Regarding the permitted range of values, I think the necessary
overhead to check that all Py_UNICODE* array values are within
the currently permitted range would unnecessarily slow down
the implementation.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Mar 31 2006)
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,FreeBSD for free !
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New-style icons, .desktop file
Hi, some time ago, someone posted in python-list about icons using the Python logo from the new site design [1]. IMO they are looking great and would be a good replacement for the old non-scaling snakes on Windows in 2.5. While we're at it, Python (and IDLE) .desktop files could be added to the distribution, making it easier for newbies on *ix platforms to start up a shell or the IDE, together with .png versions of the new icons. A pre- liminary .desktop file is available at [2], I have already created a corresponding Makefile rule locally. What do people think? Georg [1] http://mail.python.org/pipermail/python-list/2006-March/332132.html [2] https://sourceforge.net/tracker/?func=detailatid=355470aid=1353344group_id=5470 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Iterators for dict keys , values, and items == annoying :)
Taro Ogawa taroso at gmail.com writes: Nick Coghlan ncoghlan at gmail.com writes: There are three big use cases: ... delurk ... Apologies - this was posted via gmane and the post I responded to appeared in the gmane.comp.python.devel.3000 tree... I'll repost there (and check gmane a little more carefully in future). -T. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
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. That should be sufficient to cause the rest of the cycle to collapse with __del__ methods being called from the normal refcounting mechanism. So something like this: for obj in cycle: if hasattr(obj, __breakcycle__): obj.__breakcycle__() break Every object which knows it can participate in a cycle then has the option of defining a method which it can use to tear down the cycle. e.g. by releasing the resource and then deleting all of its attributes, but no guarantees are made over which obj has this method called. An object with a __breakcycle__ method would have to be extra careful as its methods could still be called after it has broken the cycle, but it does mean that the responsibilities are in the right place (i.e. defining the method implies taking that into account). Unfortunately, there's two problems with that idea: a. it's broken, since we now have a partially torn down object at the tail end of our former cycle. What happens if the penultimate object's finaliser tries to access that broken one? b.it doesn't actually help in the case of generators (which are the ones causing all the grief). The generator object itself (which implements the __del__ method) knows nothing about what caused the cycle (the cycle is going to be due to the Python code in the body of the generator). As PJE posted the other day, the problem is that the GC assumes that because the *type* has a __del__ method, the *instance* needs finalisation. And for objects with an explicit close method (like generators), context management semantics (like generator-based context managers), or the ability to be finalised in the normal course of events (like generator-iterators), most instances *don't* need finalisation, as they'll have already been finalised in the normal course of events. Generators are even more special, in that they only require finalisation in the first place if they're stopped on a yield statement inside a try-finally block. A simple Boolean attribute (e.g. __finalized__) should be enough. If the type has a __del__ method, then the GC would check the __finalized__ attribute. If it's both present and true, the GC can ignore the finaliser on that instance (i.e. never invokes it, and doesn't treat cycles as uncollectable because of it) I don't know the GC well enough to know how hard that would be to implement, but I suspect we need to do it (or something like it) if PEP 342 isn't going to cause annoying memory leaks in real applications. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
On 3/31/06, Jim Jewett [EMAIL PROTECTED] wrote: The checkins list has been struggling with generator reference leaks;the latest conclusion was that some are unavoidable because of __del__cycles. That was Tim's conclusion, but I wasn't quite done thinking about it ;) That sort of defeats the purpose of resource managers.(Yes,it can be worked around on a case-by-case basis.) As I see it, part of the problem is that(1)When there is a cycle, python refuses to guess.(2)There is no way for a __del__ method to hint at ordering constraints.(3)There is no lightweight version of __del__ to say I don't care about ordering constraints.An additional (and much more complicating) problem is that __del__ can (and is allowed to) revive 'self'. That means that halfway through your cleanup, however you decided to do it, you can suddenly find out that you shouldn't be cleaning up at all. And of course any given __del__ can rely on all of the parts of the cycle, even if one of those parts _claims_ it can safely break the cycle. I think there are three different scenarios involving cycles and/or __del__ methods:- An object may conciously create a cycle, and know how to resolve it. A '__breakcycle__' method or such may be the right way to handle those cases. It would have to be pretty sure that no one outside itself can (or should) rely on the attribute or closure it breaks the cycle with, though. (Sensible exceptions ought to be fine, IMHO.) - An object may not care about cycles, but want to do some cleanup when it is deleted. The C types have 'tp_dealloc' for this, and that's what PyFile uses to close files. If you want to emulate this behaviour in Python, you are forced to use __del__, creating the unreclaimable cycle problem. Perhaps a __dealloc__ class/staticmethod makes sense; it would be passed a dictionary of instancedata, but not 'self', so it can never revive 'self' and can be sanely used in cycles -- that is, some of its instancedata may still suddenly be None, but that's a problem with __del__ methods and global variables, too. - An object may care about cycles, actually need a __del__ method that can revive the object, but not have a sane way to say 'break the cycle at this point'. Generators may be an example of that kind of object, although I'm not sure: they could throw() an exception to end the cycle. I don't think we can reclaim cycles where none of the objects can fairly break the cycle. -- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New-style icons, .desktop file
Georg Brandl wrote: Hi, some time ago, someone posted in python-list about icons using the Python logo from the new site design [1]. IMO they are looking great and would be a good replacement for the old non-scaling snakes on Windows in 2.5. Those are *really* pretty. And the self-referential PIL source code and disassembly is just plain brilliant. . . You could even use a similar style for a Python egg icon by placing the plus-Python logo in front of a file folder picture. However, the concerns raised on python-list about the similarities between the .exe and .pyc icons are valid, IMO. I also agree with Andrew Clover's own comment that having the Windows shortcut symbol cover the Python logo on the .exe is a bad thing. One way around that would be to simply use the logo itself as the icon for the executable, and talk to Andrew about using his icons for .py/.pyw and .pyc files. While we're at it, Python (and IDLE) .desktop files could be added to the distribution, making it easier for newbies on *ix platforms to start up a shell or the IDE, together with .png versions of the new icons. A pre- liminary .desktop file is available at [2], I have already created a corresponding Makefile rule locally. Kubuntu has a Python shell as one of the options on its Terminal Sessions menu, so this part doesn't really matter to me. However, given that that box is my CPython dev machine, I probably don't qualify as one of the newbies you're targeting with this bit, anyway ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
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. While I agree with you, I don't think this conclusion is as obviously correct as it might first appear, because you don't want to decorate the class itself in such cases. You don't even want to decorate the class's __call__ method - you want to decorate an *instance* of the class, as that is what will mimic the interface of the original function. Compare: Py def f(): ...print Hi World from something! ... Py f() Hi World from something! and: Py class f(object): ... def __call__(self): ... print Hi world from %s! % self ... Py f() __main__.f object at 0x00AE1F70 Py f()() Hi world from __main__.f object at 0x00AE7130! Clearly, these two definitions of 'f' are _not_ equivalent - the first one is a callable, but the latter is a callable factory. Applying the original function's decorators to the class or its __call__ method will yield nonsense. To get an object from the second approach with an interface equivalent to the original f (only with an automatically supplied mutable data store as its first argument), you instead want to write: Py class f(object): ... def __call__(self): ... print Hi world from %s! % self ... Py f = f() Py f() Hi world from __main__.f object at 0x00AE7190! If the original f had decorators applied to it, then you would have to apply those to the final resulting bound method in the example, not to the class definition. OTOH, all is not lost, as a simple class decorator would allow Jim's use case to be satisfied quite handily: def instance(cls): return cls() Then: @deco1 @deco2 def f(): pass Could easily be replaced with: @deco1 @deco2 @instance class f(object): def __call__(self): pass Cheers, Nick. P.S. If all you want is somewhere to store mutable state between invocations, you can always use the function's own attribute space: Py def f(): ... print Hi world from %s! % f ... Py f() Hi world from function f at 0x00AE90B0! -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] x86 trunk MSI preview
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Python Regression Test Failures all (1)
On 3/1/06, Neal Norwitz [EMAIL PROTECTED] 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Python Regression Test Failures all (1)
[Neal Norwitz] 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' [and so on] [Jeremy Hylton] I haven't run regrtest.py -u all in a while. Are these sorts of errors just tolerated? test_bsddb3 has always failed in these ways, and I believe on all platforms, although on my WinXP box it only happens if my box is heavily loaded with other stuff. Normally a DBLockDeadlockError doesn't even cause the test to fail, presumably because the exception occurs in a thread unittest doesn't know about (you'll recall the convolutions we endured to get unittest to notice errors in ZODB/ZEO test threads). For example, here's a recent buildbot run where test_bsddb3 passed despite a DBLockDeadlockError: http://www.python.org/dev/buildbot/all/x86%20gentoo%20trunk/builds/223/step-test/0 The prospects for fixing it appear dim; PCbuild/readme.txt has noted for years I'm told that DBLockDeadlockError is expected at times. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
[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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
On Friday 31 March 2006 11:52, Phillip J. Eby wrote: class bar: @class foo def __init___(...): ... The more I think about it, the more I like the @class foo syntax. The existing syntax for functions doesn't have anything between the decorators and the def; having class decorators embedded within the class should still allow the docstring to be the first thing, so there's more distance between the decorator and the name being decorated. The extra hint about what's being decorated is nice. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assigned abug/patch
On 3/30/06, Fredrik Lundh [EMAIL PROTECTED] wrote: Brett Cannon wrote: Same here. Please move any more comments about infrastructure to the infrastructure list (http://mail.python.org/mailman/listinfo/infrastructure/). But do realize the committee is not discussing trackers yet. We are still trying to get our SF data out so that can be imported into a tracker to test its use oh, I forgot that the Procrastination Stop energy Foundation was involved in this. Fredrik, if you would like to help move this all forward, great; I would appreciate the help. You can write a page scraper to get the data out of SF if you don't believe SF will cooperate fast enough for your tastes or I am giving them too long to try to fix things on their end (I don't expect they will fix things fast enough either, but because of school ending soon I don't have time right now to start working on a scraper myself plus I am willing to give them a little time to try to fix the XML export so we can minimize headaches on our end). If you would rather contribute by collecting a list of possible trackers along with who will maintain it, then please do. I am not going to dive into that quite yet, but if you want to parallelize the work needed then I would appreciate the help. The tracker will need to be able to import the SF data somehow (probably will require a custom tool so the volunteers need to be aware of this), be able to export data (so we can back it up on a regular basis so we don't have to go through this again), and an email interface for at least replying to tracker items. A community-wide announcement will probably be needed to get a good group of volunteers together for any one non-commercial tracker. But I am not procrastinating. I don't think I have ever come off as a procrastinator on this list and I don't think I deserve the label. I am not putting more time in now because I am near the end of term here at school and thus passing my courses takes precendent over a new bug tracker. I ended up the chairman at the infrastructure committee during one of my busiest school terms I have ever had. But I will see this through and it will be done in a timely manner. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] gmane.comp.python.devel.3000 has disappeared
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] gmane.comp.python.devel.3000 has disappeared
Wasn't my intention. gmane is black magic to me (I've never used it) so I can't be much help debugging this... I did add 3 new admins and changed the list password. --Guido On 3/31/06, Terry Reedy [EMAIL PROTECTED] wrote: 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? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Class decorators
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] gmane.comp.python.devel.3000 has disappeared
Terry For about a week, I have been reading and occasionally posting to Terry the new pydev-3000 mailing list via the gmane mirror Terry gmane.comp.lang.devel.3000. Today, it has disappeared and was Terry still gone after reloading their newsgroup list. Was this Terry intentional on the part of the mail list maintainers? (I Terry certainly hope not!) Or is it a repairable glitch somewhere Terry between the list and gmane? Gmane is subscribed. I've sent a message to them. Hopefully they will get things corrected soon. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assigned abug/patch
Robert Kern wrote: FWIW: Trac has a Sourceforge bug tracker import script: http://projects.edgewall.com/trac/browser/trunk/contrib/sourceforge2trac.py Apologies: for the other blank reply. That isn't actually worth that much: somebody would need to operate it, too. Mere existence doesn't help. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] gmane.comp.python.devel.3000 has disappeared
On Fri, 2006-03-31 at 15:13 -0500, Terry Reedy wrote: 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? No idea, but the ng's do appear to be gone. Definitely not intentional on our part! -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] reference leaks, __del__, and annotations
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] gmane.comp.python.devel.3000 has disappeared
Guido van Rossum [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Wasn't my intention. Good ;-) gmane is black magic to me (I've never used it) so I can't be much help debugging this... I did add 3 new admins and changed the list password. Since one of the last messages I read was your announcement of the coming changeover, I suspect some part of that might be the cause. Skip Gmane is subscribed. I've sent a message to them. Hopefully they will get things corrected soon. I posted a note to gmane.discuss before I read the second sentence. But I will probably have to confirm my humaness before it goes thru, so I will let it sit a day first. Thanks for responding. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
Nick Coghlan wrote: Generators are even more special, in that they only require finalisation in the first place if they're stopped on a yield statement inside a try-finally block. I find it rather worrying that there could be a few rare cases in which my generators cause memory leaks, through no fault of my own and without my being able to do anything about it. Will there be a coding practice one can follow to ensure that this doesn't happen? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
Jim Jewett wrote: 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. Well, true. If you want it to be bullet-proof, you have to use a closure instead: def make_f(): ... def f(): ... print Hi world from %s! % f ... return f ... f = make_f() f() Hi world from function f at 0x00AE90B0! The point about the decorators still holds - they stay with the function they're decorating (the inner one), and you don't need to make any of the changes needed in order to decorate the class instead. The above is also a use case for a *function* decorator I've occasionally wanted - an @result decorator, that is the equivalent of the @instance decorator I suggested for classes: def result(f): ... return f() ... @result ... def f(): ... def f(): ... print Hi world from %s! % f ... return f ... f() Hi world from function f at 0x00AE90B0! I never actually did it, though, as I was stuck on Python 2.2 at the time. This is something of a tangent to the real discussion though, so I'll leave this one there :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
Greg Ewing wrote: Nick Coghlan wrote: Generators are even more special, in that they only require finalisation in the first place if they're stopped on a yield statement inside a try-finally block. I find it rather worrying that there could be a few rare cases in which my generators cause memory leaks, through no fault of my own and without my being able to do anything about it. The GC changes PJE is looking at are to make sure you *can* do something about it. If the generator hasn't been started, or has already finished, then the GC won't consider it as needing finalisation. Will there be a coding practice one can follow to ensure that this doesn't happen? I believe PJE's fix should take care of most cases (depending on how aggressive we can safely be, it may even take care of all of them). If there are any remaining cases, I think the main thing is to avoid keeping half-finished generators around: from contextlib import closing with closing(itr): # Use the iterator in here as you wish # secure in the knowledge it will be # cleaned up promptly when you are done # whether it is a file, a generator or # something with a database connection for item in itr: print item Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
Nick Coghlan wrote: from contextlib import closing with closing(itr): # Use the iterator in here as you wish # secure in the knowledge it will be # cleaned up promptly when you are done # whether it is a file, a generator or # something with a database connection for item in itr: print item I seem to remember we've been here before. I'll be disappointed if I have to wrap every for-loop that I write in a with-statement on the offchance that it might be using a generator that needs finalisation in order to avoid leaking memory. I'm becoming more and more convinced that we desperately need something better than __del__ methods to do finalisation. A garbage collector that can't be relied upon to collect garbage is simply not acceptable. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
