On 3 Aug 2013 11:07, "Terry Reedy" <tjreedy(a)udel.edu> wrote:
> On 8/2/2013 6:19 AM, nick.coghlan wrote:
>> +The Python standard library is conservative and requires limiting
>> +lines to 79 characters (and docstrings/comments to 72).
> If you (and Guido) mean that as a hard limit, then patchcheck should
check line lengths as well as trailing whitespace.
That raises issues when modifying existing non-compliant files, because it
removes the human judgement on whether a non-compliance is worth fixing or
> Python-checkins mailing list
I have a few more questions on the PEP 446:
(A) How should we support support where os.set_inheritable() is not
supported? Can we announce that os.set_inheritable() is always
available or not? Does such platform exist?
(B) Should subprocess make the file descriptors of pass_fds
inheritable? If yes, should it be done before or after the fork? If it
is done after the fork and before exec, it only affects the child
process, at least on Linux (the file descriptor is still
non-inheritable in the parent process).
(C) Should we handle standard streams (0: stdin, 1: stdout, 2: stderr)
differently? For example, os.dup2(fd, 0) should make the file
descriptor 0 (stdin) inheritable or non-inheritable? On Windows,
os.set_inheritable(fd, False) fails (error 87, invalid argument) on
standard streams (0, 1, 2) and copies of the standard streams (created
PEP 442 has now been committed in time for testing in Alpha 1.
This paves the way for the removal of another well-known annoyance: the
behaviour of module globals at shutdown. Now that reference cycles
aren't a barrier to object finalization anymore, we shouldn't need
to set module globals to None before trying to reclaim modules.
(and then, we don't need to cache global functions for use in
I have a patch to suppress the hack in
Once I get to add some tests, I would like to commit it soon too!