Re: [Python-Dev] Iterator version of contextlib.nested
I actually almost asked for that to be changed to a PendingDeprecationWarning when it was first added - Benjamin, do you mind if I downgrade this warning to a pending one post rc2? I'm not sure what that would buy us. For the use case I mentioned it would be just as annoying to get a PendingDeprecationWarning. But if the warning was completely removed now, nested could still get deprecated in 3.2 as soon as some better mechanism for a variable number of managers has been provided. - Hagen ___ 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] ctime: I don't think that word means what you think it means.
On Sun, 14 Jun 2009 10:40:53 am Greg Ewing wrote: Zooko Wilcox-O'Hearn wrote: 1. Add a st_crtime field which gets populated on filesystems (Windows, ZFS, Mac) which can do so. crtime looks rather too similar to ctime for my liking. People who think that the c in ctime means creation are still likely to confuse them. Why not give it a more explicit name, such as st_creationtime? Speaking as somebody who thought the c in ctime meant creation, I'm +1 on this proposal with Greg's modification. -- Steven D'Aprano ___ 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] ctime: I don't think that word means what you think it means.
Steven D'Aprano wrote: On Sun, 14 Jun 2009 10:40:53 am Greg Ewing wrote: Zooko Wilcox-O'Hearn wrote: 1. Add a st_crtime field which gets populated on filesystems (Windows, ZFS, Mac) which can do so. crtime looks rather too similar to ctime for my liking. People who think that the c in ctime means creation are still likely to confuse them. Why not give it a more explicit name, such as st_creationtime? My this bike-shed looks a bit greenish. How about: creation_time or, at least, st_creation_time Speaking as somebody who thought the c in ctime meant creation, I'm +1 on this proposal with Greg's modification. --Scott David Daniels scott.dani...@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] io.BufferedReader.peek() Behaviour in python3.1
2009/6/14 Cameron Simpson c...@zip.com.au: On 14Jun2009 15:16, I wrote: | Is it possible to access the buffer? I see nothing in the docs. I've just found getvalue() in IOBase. Forget I said anything. It seems to be my day for that kind of post:-( Where are you seeing this? Only BytesIO and StringIO have a getvalue() method. -- Regards, Benjamin ___ 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] Iterator version of contextlib.nested
2009/6/13 Nick Coghlan ncogh...@gmail.com: Hagen Fürstenau wrote: I guess this is much too late for 3.1, but could we then at least un-deprecate contextlib.nested for now? As it is, you get a DeprecationWarning for something like with contextlib.nested(*my_managers): without any good way to get rid of it. I actually almost asked for that to be changed to a PendingDeprecationWarning when it was first added - Benjamin, do you mind if I downgrade this warning to a pending one post rc2? Yes, I think that's a good idea. It will also help people who have to use contextlib.nested() for backwards compatibility. -- Regards, Benjamin ___ 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] CPython in the web browser under Native Client
I have been doing some work to extend Google's Native Client [1] to support dynamic linking [2]. For those who haven't heard of it, Native Client is a sandboxing system for running a subset of x86 code. It is proposed as a way of running native code inside web apps. One of my aims has been to get CPython working in the web browser under Native Client without having to modify CPython. I recently got to the point where modules from the Python standard library are importable under Native Client, including (as a demonstration) the Sqlite extension module. Sqlite also requires no modification - it builds straight from the Debian package. I've written a simple REPL to demonstrate Python running in the browser. There are some screenshots on my blog [3]. I haven't implemented accessing the DOM from Python yet - that's another project for later. :-) Mark [1] http://code.google.com/p/nativeclient/ [2] http://plash.beasts.org/wiki/NativeClient [3] http://lackingrhoticity.blogspot.com/2009/06/python-standard-library-in-native.html ___ 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] Avoiding file descriptors leakage in subprocess.Popen()
Facundo Batista facundobati...@gmail.com wrote: errpipe_read, errpipe_write = os.pipe() try: try: . . . . . . finally: os.close(errpipe_write) . . . finally: os.close(errpipe_read) I just don't like a huge try/finally... but as FDs are just ints, do you think is there a better way to handle it? I use a convenience function like this, so that GC takes care of the FDs: def make_pipe(): read_fd, write_fd = os.pipe() return os.fdopen(read_fd, r), os.fdopen(write_fd, w) Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Exception for setting attributes of built-in type
Exception for setting attributes of built-in type differs between CPython and IronPython. This is not purely theoretical, as zope.interface tries to set Implements declaration as __implemented__ attribute of built-in type object, and excepts TypeError. Python 2.6.1 object.flag = True TypeError: can't set attributes of built-in/extension type 'object' IronPython 2.6 object.flag = True AttributeError: 'object' object has no attribute 'flag' I was surprised that CPython raises TypeError. Library Reference seems to mention it here: exception AttributeError Raised when an attribute reference or assignment fails. (When an object does not support attribute references or attribute assignments at all, TypeError is raised.) http://docs.python.org/library/exceptions.html What does it mean that an object does not support attribute references or attribute assignments at all? -- Seo Sanghyeon ___ 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] Exception for setting attributes of built-in type
Seo Sanghyeon wrote: Exception for setting attributes of built-in type differs between CPython and IronPython. This is not purely theoretical, as zope.interface tries to set Implements declaration as __implemented__ attribute of built-in type object, and excepts TypeError. Python 2.6.1 object.flag = True TypeError: can't set attributes of built-in/extension type 'object' IronPython 2.6 object.flag = True AttributeError: 'object' object has no attribute 'flag' I was surprised that CPython raises TypeError. Library Reference seems to mention it here: exception AttributeError Raised when an attribute reference or assignment fails. (When an object does not support attribute references or attribute assignments at all, TypeError is raised.) http://docs.python.org/library/exceptions.html What does it mean that an object does not support attribute references or attribute assignments at all? I see it as slightly ambiguous: 1. It neither supports references nor assignments. 2. It either does not support reference or it does not support assignments. 1 could hardly apply any more, certainly to built-ins since everything now has attributes. 2 covers object, so if that is meant, then TypeError is appropriate. Or were you unclear about 'at all', which means 'never'? 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] Exception for setting attributes of built-in type
Seo Sanghyeon wrote: Exception for setting attributes of built-in type differs between CPython and IronPython. This is not purely theoretical, as zope.interface tries to set Implements declaration as __implemented__ attribute of built-in type object, and excepts TypeError. Python 2.6.1 object.flag = True TypeError: can't set attributes of built-in/extension type 'object' IronPython 2.6 object.flag = True AttributeError: 'object' object has no attribute 'flag' I was surprised that CPython raises TypeError. Library Reference seems to mention it here: exception AttributeError Raised when an attribute reference or assignment fails. (When an object does not support attribute references or attribute assignments at all, TypeError is raised.) http://docs.python.org/library/exceptions.html What does it mean that an object does not support attribute references or attribute assignments at all? Here's my guess: Some objects have a fixed (and possibly empty) set of attributes. Attempting to add a new attribute or get a non-existent attribute raises an AttributeError. Other objects, such as types (are there any that aren't types?), don't have attributes at all. Attempting to add or get an attribute raises a TypeError. ___ 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] CPython in the web browser under Native Client
Wow. I'm impressed. On Sun, Jun 14, 2009 at 9:09 AM, Mark Seabornm...@mythic-beasts.com wrote: I have been doing some work to extend Google's Native Client [1] to support dynamic linking [2]. For those who haven't heard of it, Native Client is a sandboxing system for running a subset of x86 code. It is proposed as a way of running native code inside web apps. One of my aims has been to get CPython working in the web browser under Native Client without having to modify CPython. I recently got to the point where modules from the Python standard library are importable under Native Client, including (as a demonstration) the Sqlite extension module. Sqlite also requires no modification - it builds straight from the Debian package. I've written a simple REPL to demonstrate Python running in the browser. There are some screenshots on my blog [3]. I haven't implemented accessing the DOM from Python yet - that's another project for later. :-) Mark [1] http://code.google.com/p/nativeclient/ [2] http://plash.beasts.org/wiki/NativeClient [3] http://lackingrhoticity.blogspot.com/2009/06/python-standard-library-in-native.html ___ 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/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception for setting attributes of built-in type
On Sun, Jun 14, 2009 at 3:42 PM, MRABpyt...@mrabarnett.plus.com wrote: Seo Sanghyeon wrote: Exception for setting attributes of built-in type differs between CPython and IronPython. This is not purely theoretical, as zope.interface tries to set Implements declaration as __implemented__ attribute of built-in type object, and excepts TypeError. Python 2.6.1 object.flag = True TypeError: can't set attributes of built-in/extension type 'object' IronPython 2.6 object.flag = True AttributeError: 'object' object has no attribute 'flag' I was surprised that CPython raises TypeError. Library Reference seems to mention it here: exception AttributeError Raised when an attribute reference or assignment fails. (When an object does not support attribute references or attribute assignments at all, TypeError is raised.) http://docs.python.org/library/exceptions.html What does it mean that an object does not support attribute references or attribute assignments at all? Here's my guess: Some objects have a fixed (and possibly empty) set of attributes. Attempting to add a new attribute or get a non-existent attribute raises an AttributeError. Other objects, such as types (are there any that aren't types?), don't have attributes at all. Attempting to add or get an attribute raises a TypeError. This particular error comes (grep tells me :-) from type_setattro() in Objects/typeobject.c. It makes a specific check whether the type object whose attribute you want to set is a built-in type (this is done by checking the HEAPTYPE flag, which is never set for built-in types and always for user-defined types). For built-in types it disallows setting attributes. This is a pure policy issue: it prevents different 3rd party modules to make incompatible modifications of built-in types. In general, CPython isn't always consistent in raising AttributeError and TypeError when it comes to such policy issues: there are various places that raise TypeError in typeobject.c (and probably elsewhere) that simply forbid setting a specific attribute (another example is __name__). Given how poorly Python exceptions are specified in general, I don't want to hold IronPython to this standard (nor CPython :-). The reason this breaks zope.interfaces in IronPython is probably just that zope.interfaces was primarily written/tested against CPython. Going back to the phrase quoted from the reference manual, it's probably referring to the possibility that a type's tp_getattro slot is NULL; but even so it's wrong: PyObject_GetAttr() raises AttributeError in this case. Uselessly y'rs, -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1
Cameron Simpson wrote: For myself, I'd expect more often to want to see if there's stuff in the buffer _without_ doing any raw reads at all. What uses do you have in mind for that? -- 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] io.BufferedReader.peek() Behaviour in python3.1
On 14Jun2009 09:21, Benjamin Peterson benja...@python.org wrote: | 2009/6/14 Cameron Simpson c...@zip.com.au: | On 14Jun2009 15:16, I wrote: | | Is it possible to access the buffer? I see nothing in the docs. | | I've just found getvalue() in IOBase. Forget I said anything. | It seems to be my day for that kind of post:-( | | Where are you seeing this? Only BytesIO and StringIO have a getvalue() method. I had thought I'd traced it by class inheritance. But I got BytesIO and IOBase confused. So: no getvalue then. So probably there is a case for peek0(), which never does a raw read. Thoughts? -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ I was gratified to be able to answer promptly and I did. I said I didn't know. - Mark Twain ___ 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] io.BufferedReader.peek() Behaviour in python3.1
On 15Jun2009 11:48, Greg Ewing greg.ew...@canterbury.ac.nz wrote: For myself, I'd expect more often to want to see if there's stuff in the buffer _without_ doing any raw reads at all. What uses do you have in mind for that? It seems like whenever I want to do some kind of opportunistic but non-blocking stuff with a remote service (eg something I have a packetising connection to, such as a TCP stream) I want to be able to see if there's more stuff to gather up before issuing a flush operation. And I want to be able to do that in a non-blocking way, much as a Queue has a non-blocking get() method. As an example, I've got the occasional protocol handler where it has to make a remote query. To avoid deadlock, the stream must be flushed after write()ing the query packet. However, flushing on every such packet is horribly wasteful if you know you have a bunch of them (for example, the caller is asking a bunch of questions). It is far far more efficient to write() each packet without flushes, keep the knowledge that a flush is needed, and flush when there's nothing more pending. That way the lower layer has maximum opportunity to pack data into packets. All that presumes another thread reading responses, which is how I generally write this stuff anyway, otherwise a full buffer will deadlock too. So your dispatch thread inner loop looks like this: # single consumer, so Q.empty() implies ok to Q.get() needFlush = False while not Q.empty(): P=Q.get() if P.needFlush: needFlush = True out.write(P.serialise()) if needFlush: out.flush() In this scheme, there _are_ packets that don't need a flush, because nobody is waiting on their response. Anyway, if I were reading from an IO object instead of a Queue I'd want to poll for buffer empty. If there isn't an empty buffer I know there will be a packet worth of data coming immediately and I can pick it up with regular read()s, just as I'm doing with Q.get() above. But if the buffer is empty I can drop out of the pick it all up now loop and flush(). Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ If you take something apart and put it back together again enough times, you will eventually have enough parts left over to build a second one. - Ayse Sercan a...@netcom.com ___ 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] Iterator version of contextlib.nested
FWIW, I think resurrecting contextlib.nested() is a bad idea. Part of the justification for the new with-statement syntax was that nested() doesn't have a way to finalize the constructors if one of them fails. It is a pitfall for the unwary. And now that we have the new with-statement syntax, it mostly just represents a second-way-to-do-it (a second way that has has the stated pitfall). The new statement was not designed to support passing in tuples of context-managers. This issue was raised while the new with-statement was being designed and it was intentionally left-out (in part, because the use cases were questionable and in-part because there were other ways to do it such as adding __enter__ and __exit__ to tuple). I suggest a PEP for 2.7 and 3.2 for building-out the with-statement to support tuples of context managers (perhaps modeled after the syntax for except-statements which allows either individual exceptions or tuples of exceptions). The reason I suggest a PEP is that use cases need to be fully thought out and the failing constructor problem needs to be dealt with. IMO, this represents doing-it-the-right-way instead of preserving a construct that is known to be problematic. Leaving it in will enshrine it. Better to just provide our new syntax that correctly handles the common case and then wait to carefully think through how to add support for passed-in nested cm's if in-fact those turn-out to have reasonable use cases. Raymond ___ 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] Iterator version of contextlib.nested
2009/6/14 Raymond Hettinger pyt...@rcn.com: FWIW, I think resurrecting contextlib.nested() is a bad idea. Part of the justification for the new with-statement syntax was that nested() doesn't have a way to finalize the constructors if one of them fails. It is a pitfall for the unwary. And now that we have the new with-statement syntax, it mostly just represents a second-way-to-do-it (a second way that has has the stated pitfall). I don't consider changing a DeprecationWarning to a PendingDeprecationWarning resurrecting its target. Fully deprecating a feature in the same version that we add its replacement will just make more difficulties for cross-version libraries. I suggest a PEP for 2.7 and 3.2 for building-out the with-statement to support tuples of context managers (perhaps modeled after the syntax for except-statements which allows either individual exceptions or tuples of exceptions). I think the question of extending the syntax later is orthogonal to the issue of the DeprecationWarning. -- Regards, Benjamin ___ 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
