Re: [Python-Dev] cpython: Issue #18571: Implementation of the PEP 446: file descriptors and file handles
On 08/28/2013 01:20 AM, victor.stinner wrote: > http://hg.python.org/cpython/rev/ef889c3d5dc6 > changeset: 85420:ef889c3d5dc6 > user:Victor Stinner > date:Wed Aug 28 00:53:59 2013 +0200 > summary: > Issue #18571: Implementation of the PEP 446: file descriptors and file > handles > are now created non-inheritable; add functions os.get/set_inheritable(), > os.get/set_handle_inheritable() and socket.socket.get/set_inheritable(). > +.. _fd_inheritance: > + > +Inheritance of File Descriptors > +~~~ > + > +A file descriptor has a inheritable flag which indicates if the file > descriptor > +can be inherited or not in child processes. Since Python 3.4, file > descriptors > +created by Python are non-inheritable by default. > + > +On UNIX, non-inheritable file descriptors are closed in child processes at > the > +execution of a new program, other file descriptors are inherited. > + > +On Windows, non-inheritable handles and file descriptors are closed in child > +processes, except standard streams (file descriptors 0, 1 and 2: stdin, > stdout > +and stderr) which are always inherited. Using :func:`os.spawn*` functions, > +all inheritable handles and all inheritable file descriptors are inherited. > +Using the :mod:`subprocess` module, all file descriptors except standard > +streams are closed, inheritable handles are only inherited if the *close_fds* > +parameter is ``False``. > + > +.. versionadded:: 3.4 > + > +.. function:: get_inheritable(fd) > + > + Get the `inheritable flag `_ of the specified file > + descriptor. Return a :class:`bool`. > + > +.. function:: set_inheritable(fd, inheritable) > + > + Set the `inheritable flag `_ of the specified file > descriptor. > + > +.. function:: get_handle_inheritable(handle) > + > + Get the `inheritable flag `_ of the specified handle. > Return a :class:`bool`. > + > + Availability: Windows. > + > +.. function:: set_handle_inheritable(handle, inheritable) > + > + Set the `inheritable flag `_ of the specified handle. > + > + Availability: Windows. > + "Handle" is used nowhere else in the os module documentation. Do you think it would make sense to have a brief paragraph on what are possible handles under Windows (and that file descriptors aren't handles)? Georg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On Sun, 15 Sep 2013 13:56:26 +0900 Larry Hastings wrote: > On 09/14/2013 07:30 PM, Antoine Pitrou wrote: > > On Sat, 14 Sep 2013 14:33:56 +0900 > > Larry Hastings wrote: > >> Whenever I read a discussion about the dict, I always wonder whether the > >> same thing applies to a set. Have you considered the utility of a > >> TransformSet? Or is it YAGNI? > > Well, a TransformSet is like a normal dict, you just need to call the > > transformation function yourself when inserting the keys. > > s/normal dict/normal set/ No, read my example. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
15.09.13 14:23, Antoine Pitrou написав(ла): On Sun, 15 Sep 2013 13:56:26 +0900 Larry Hastings wrote: On 09/14/2013 07:30 PM, Antoine Pitrou wrote: On Sat, 14 Sep 2013 14:33:56 +0900 Larry Hastings wrote: Whenever I read a discussion about the dict, I always wonder whether the same thing applies to a set. Have you considered the utility of a TransformSet? Or is it YAGNI? Well, a TransformSet is like a normal dict, you just need to call the transformation function yourself when inserting the keys. s/normal dict/normal set/ No, read my example. A TransformDict is like a normal dict, you just need to call the transformation function yourself when inserting the keys and insert a pair of (orig_key, value), or is like two normal dicts, you just need to call the transformation function yourself when inserting the keys and update parallel mapping from transformed keys to original keys. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On Sun, 15 Sep 2013 16:14:24 +0300 Serhiy Storchaka wrote: > 15.09.13 14:23, Antoine Pitrou написав(ла): > > On Sun, 15 Sep 2013 13:56:26 +0900 > > Larry Hastings wrote: > >> On 09/14/2013 07:30 PM, Antoine Pitrou wrote: > >>> On Sat, 14 Sep 2013 14:33:56 +0900 > >>> Larry Hastings wrote: > Whenever I read a discussion about the dict, I always wonder whether the > same thing applies to a set. Have you considered the utility of a > TransformSet? Or is it YAGNI? > >>> Well, a TransformSet is like a normal dict, you just need to call the > >>> transformation function yourself when inserting the keys. > >> > >> s/normal dict/normal set/ > > > > No, read my example. > > A TransformDict is like a normal dict, you just need to call the > transformation function yourself when inserting the keys and insert a > pair of (orig_key, value), or is like two normal dicts, you just need to > call the transformation function yourself when inserting the keys and > update parallel mapping from transformed keys to original keys. I don't really care. What's the point in the end? TransformDict is non-trivial to implement, while the so-called "TransformSet" is just a dict with a different API. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #18571: Implementation of the PEP 446: file descriptors and file handles
Yes, but I'm not interested to write such doc. Victor Le 15 sept. 2013 10:34, "Georg Brandl" a écrit : > On 08/28/2013 01:20 AM, victor.stinner wrote: > > http://hg.python.org/cpython/rev/ef889c3d5dc6 > > changeset: 85420:ef889c3d5dc6 > > user:Victor Stinner > > date:Wed Aug 28 00:53:59 2013 +0200 > > summary: > > Issue #18571: Implementation of the PEP 446: file descriptors and file > handles > > are now created non-inheritable; add functions os.get/set_inheritable(), > > os.get/set_handle_inheritable() and socket.socket.get/set_inheritable(). > > > +.. _fd_inheritance: > > + > > +Inheritance of File Descriptors > > +~~~ > > + > > +A file descriptor has a inheritable flag which indicates if the file > descriptor > > +can be inherited or not in child processes. Since Python 3.4, file > descriptors > > +created by Python are non-inheritable by default. > > + > > +On UNIX, non-inheritable file descriptors are closed in child processes > at the > > +execution of a new program, other file descriptors are inherited. > > + > > +On Windows, non-inheritable handles and file descriptors are closed in > child > > +processes, except standard streams (file descriptors 0, 1 and 2: stdin, > stdout > > +and stderr) which are always inherited. Using :func:`os.spawn*` > functions, > > +all inheritable handles and all inheritable file descriptors are > inherited. > > +Using the :mod:`subprocess` module, all file descriptors except standard > > +streams are closed, inheritable handles are only inherited if the > *close_fds* > > +parameter is ``False``. > > + > > +.. versionadded:: 3.4 > > + > > +.. function:: get_inheritable(fd) > > + > > + Get the `inheritable flag `_ of the specified file > > + descriptor. Return a :class:`bool`. > > + > > +.. function:: set_inheritable(fd, inheritable) > > + > > + Set the `inheritable flag `_ of the specified file > descriptor. > > + > > +.. function:: get_handle_inheritable(handle) > > + > > + Get the `inheritable flag `_ of the specified > handle. Return a :class:`bool`. > > + > > + Availability: Windows. > > + > > +.. function:: set_handle_inheritable(handle, inheritable) > > + > > + Set the `inheritable flag `_ of the specified handle. > > + > > + Availability: Windows. > > + > > "Handle" is used nowhere else in the os module documentation. Do you > think it > would make sense to have a brief paragraph on what are possible handles > under > Windows (and that file descriptors aren't handles)? > > Georg > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 428: Pathlib
I see PEP 428 is both targeted at 3.4 and still in draft status. What remains to be done to ask for pronouncement? -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 422: Simpler customisation of class creation
Three questions: Would the new __initclass__ function be usable with actual full-blown metaclasses? The PEP says this: If present on the created object, this new hook will be called by the class creation machinery after the __class__ reference has been initialised. Given that statement, and this example: class A: def __initclass__(cls): # do stuff class B(A): pass am I correct that A's __initclass__ will not run when B is created? Where are we at with being ready for pronouncement? -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 422: Simpler customisation of class creation
On 16 September 2013 00:19, Ethan Furman wrote: > Three questions: > > > Would the new __initclass__ function be usable with actual full-blown > metaclasses? Sure (as long as the metaclass in question called it at the appropriate time, which those inheriting from type would do automatically)). > The PEP says this: >> If present on the created object, this new hook will be called by the >> class creation machinery after the __class__ reference has been initialised. > > > Given that statement, and this example: > > class A: > def __initclass__(cls): > # do stuff > > class B(A): > pass > > am I correct that A's __initclass__ will not run when B is created? No, that would be pointless (since that's the way class decorators already behave). "present on the created object" means "hasattr(cls, '__initclass__') returns True. > Where are we at with being ready for pronouncement? The PEP needs to be updated to incorporate the feedback from the last time I proposed it for inclusion. That's not going to happen for 3.4, I just forgot to mark it as Deferred - fixed now. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
15.09.13 16:57, Antoine Pitrou написав(ла): I don't really care. What's the point in the end? TransformDict is non-trivial to implement, while the so-called "TransformSet" is just a dict with a different API. I don't see a difference. To me TransformDict is just a dict (or two). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On Sun, 15 Sep 2013 17:45:00 +0300 Serhiy Storchaka wrote: > 15.09.13 16:57, Antoine Pitrou написав(ла): > > I don't really care. What's the point in the end? TransformDict is > > non-trivial to implement, while the so-called "TransformSet" is just a > > dict with a different API. > > I don't see a difference. To me TransformDict is just a dict (or two). Well, feel free to propose a TransformSet PEP, but please do so in a separate discussion thread. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
On 16 September 2013 00:45, Serhiy Storchaka wrote: > 15.09.13 16:57, Antoine Pitrou написав(ла): > >> I don't really care. What's the point in the end? TransformDict is >> non-trivial to implement, while the so-called "TransformSet" is just a >> dict with a different API. > > > I don't see a difference. To me TransformDict is just a dict (or two). I think it's best to hold off a TransformSet, since you can trivially emulate it by setting the values in a TransformDict to None (that's how Python itself lived without a set type for so long: people just used dicts with all the values set to None). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Relative path in co_filename for zipped modules
This bug has been reported as http://bugs.python.org/issue18307 over a month ago Аnd I've found out the root cause of this issue so far. Unit-test and patch are suggested. Without patch test fails, with patch - passed. On Wed, Jun 26, 2013 at 12:11 AM, Vitaly Murashev wrote: > Dear Python developers community, > > Recently I found out that it not possible to debug python code if it > is a part of zip-module. > Python version being used is 3.3.0 > > Well known GUI debuggers like Eclipse+PyDev or PyCharm are unable to > start debugging and give the following warning: > --- > pydev debugger: CRITICAL WARNING: This version of python seems to be > incorrectly compiled (internal generated filenames are not absolute) > pydev debugger: The debugger may still function, but it will work > slower and may miss breakpoints. > --- > So I started my own investigation of this issue and results are the > following. > > At first I took traditional python debugger 'pdb' to analyze how it > behaves during debugging of zipped module. > 'pdb' showed me some backtaces and filename part for stack entries > looks malformed. > I expected something like > 'full-path-to-zip-dir/my_zipped_module.zip/subdir/test_module.py' > but realy it looks like 'full-path-to-current-dir/subdir/test_module.py' > > Source code in pdb.py and bdb.py (which one are a part of python > stdlib) gave me the answer why it happens. > > The root cause are inside Bdb.format_stack_entry() + Bdb.canonic() > > Please take a look at the following line inside 'format_stack_entry' > method: > > filename = self.canonic(frame.f_code.co_filename) > > For zipped module variable 'frame.f_code.co_filename' holds _relative_ > file path started from the root of zip archive like > 'subdir/test_module.py' > And as result Bdb.canonic() method gives what we have - > 'full-path-to-current-dir/subdir/test_module.py' > --- > So my final question. > Could anyone confirm that it is a bug in python core subsystem which > one is responsible for loading zipped modules, > or something is wrong with my zipped module ? > > If it is a bug could you please submit it into official python bugtracker ? > I never did it before and afraid to do something wrong. > > Thanks, > Vitaly Murashev > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] TransformDict (PEP 455) Naming
Does anybody know if http://vote.python.org is already operational? I decided to start a separate thread for TransformDict name, because I want to change it. Current implementation of PEP 455 only touches dictionary keys and it is more narrow than the name suggests. I'd reserve TransformDict name for something that is used to transform some other data. For my data transformation theory I have an idea of mapping with annotated fields that is used to change the names of some source data structure to target data structure, converting types and applying custom rules on the way. This is a different, but more intuitive application of such name. Name for the PEP 455 should be less abstract, more specialized. Which transform? What is transformed? Where the transformation is taking place? How it is going to be used? Why do you need a generalized structure? In PEP 455 I see two use cases only. 1. Case-insensitive keys. dictik() - dictionary with insensitive keys 2. Identity dict. dictik() - dictionary with implicit keys The generic name for collections entry can be VagueKeysDict() or DynamicKeysDict() or DynKeyDict(). The name should tell what's going on with the type to people completely unfamiliar with concept. OrderedDict() is a good name - dict with ordered entries, NamedTuple() is so-so - tuple that has a name, but also ok. TransformDict() is just too generic and doesn't tell anything - something is transformed, or dict somehow transformed, or dict for transform. There should be a better name. -- anatoly t. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
