On 12.01.13 17:45, eli.bendersky wrote:
http://hg.python.org/cpython/rev/bbfc8f62cb67
changeset: 81452:bbfc8f62cb67
branch: 3.3
parent: 81450:f9d1d120c19e
user:Eli Bendersky eli...@gmail.com
date:Sat Jan 12 07:44:32 2013 -0800
summary:
clean trailing whitespace
Hello,
PEP: 433
Title: Add cloexec argument to functions creating file descriptors
I'm not a native English speaker, but it seems to me that the correct
wording should be parameter (part of the function
definition/prototype, whereas argument refers to the actual value
supplied).
This PEP
On Sun, Jan 13, 2013 at 2:40 AM, Charles-François Natali
cf.nat...@gmail.com wrote:
Hello,
PEP: 433
Title: Add cloexec argument to functions creating file descriptors
I'm not a native English speaker, but it seems to me that the correct
wording should be parameter (part of the function
On Sun, Jan 13, 2013 at 8:40 PM, Charles-François Natali
cf.nat...@gmail.com wrote:
Hello,
PEP: 433
Title: Add cloexec argument to functions creating file descriptors
I'm not a native English speaker, but it seems to me that the correct
wording should be parameter (part of the function
On Sun, Jan 13, 2013 at 8:40 PM, Charles-François Natali
cf.nat...@gmail.com wrote:
XXX Should ``subprocess.Popen`` set the close-on-exec flag on file XXX
XXX descriptors of the constructor the ``pass_fds`` argument? XXX
What?
Setting them cloexec would prevent them from being inherited
On Sun, 13 Jan 2013 21:13:42 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Also, ISTM that Windows also supports this flag. If it does, then
cloexec might not be the best name, because it refers to the
execve() Unix system call. Maybe something like noinherit would be
clearer (although
On Sun, Jan 13, 2013 at 9:15 PM, Antoine Pitrou solip...@pitrou.net wrote:
It also means we're free to implement a mechanism that tries to close
all sensitive file descriptors in _PyOS_AfterFork.
Ouch! This actually shows that noinherit is a very bad name. The PEP
is about closing fds after
On Sun, 13 Jan 2013 21:33:30 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Jan 13, 2013 at 9:15 PM, Antoine Pitrou solip...@pitrou.net wrote:
It also means we're free to implement a mechanism that tries to close
all sensitive file descriptors in _PyOS_AfterFork.
Ouch! This actually
On Sun, Jan 13, 2013 at 9:43 PM, Antoine Pitrou solip...@pitrou.net wrote:
As for the opacity, feel free to propose something better
(close_on_spawn, whatever). But I'm definitely and strongly -1
on noinherit.
That's the main reason I quite like sensitive as a term for this,
since it decouples
On Sun, 13 Jan 2013 22:44:06 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Jan 13, 2013 at 9:43 PM, Antoine Pitrou solip...@pitrou.net wrote:
As for the opacity, feel free to propose something better
(close_on_spawn, whatever). But I'm definitely and strongly -1
on noinherit.
On Sun, Jan 13, 2013 at 11:22 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 13 Jan 2013 22:44:06 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Jan 13, 2013 at 9:43 PM, Antoine Pitrou solip...@pitrou.net wrote:
As for the opacity, feel free to propose something better
On Sun, 13 Jan 2013 23:49:32 +1000
Nick Coghlan ncogh...@gmail.com wrote:
(it's not even just a security issue: letting a bound socket open and
therefore being unable to re-use the same port is a bug even when
security is not a concern)
Agreed, but it's the security implications that
Alternatives
Always set close-on-exec flag
-
Oops, this is completly wrong. This section is basically exactly the
same than the PEP proposal, except that the default value of cloexec
is set to True. The correct title is: Set the close-on-exec flag by
On 13.01.13 16:28, eli.bendersky wrote:
http://hg.python.org/cpython/rev/f0e80c7404a5
changeset: 81490:f0e80c7404a5
user:Eli Bendersky eli...@gmail.com
date:Sun Jan 13 06:27:51 2013 -0800
summary:
Cleanup the docs ElementTree a bit and describe the default_namespace
And perhaps it will be better if parameters will be described in same
order as they enumerated in the signature (now 'default_namespace'
described after 'method').
___
Python-Dev mailing list
Python-Dev@python.org
On Sun, Jan 13, 2013 at 1:15 AM, Bruce Sherwood bruce_sherw...@ncsu.edu wrote:
Here is detailed information on how VPython 6 differs from VPython 5, which
will be incorporated in the Help for upcoming releases of VPython 6. Note
that the fact that in a main program __name__ isn't '__main__' is
On Sun, Jan 13, 2013 at 7:31 AM, Serhiy Storchaka storch...@gmail.comwrote:
And perhaps it will be better if parameters will be described in same
order as they enumerated in the signature (now 'default_namespace'
described after 'method').
Serhiy, both you comments make sense. But:
1. A
On 13.01.13 19:28, Eli Bendersky wrote:
1. A better place to park them is an issue (the original issue for
which the commits were made, or even a new issue).
I agree. Usually I do this, except for the cases when the issue number
is not specified in the commit message.
2. Feel free to use
Nick Coghlan wrote:
Agreed, but it's the security implications that let us even
contemplate the backwards compatibility break.
I don't think that's a sufficient criterion for choosing a
name. The backwards compatibility issue is a transitional
thing, but we'll be stuck with the name forever.
On Sun, Jan 13, 2013 at 12:14 PM, Bruce Sherwood
bruce_sherw...@ncsu.edu wrote:
For the record, I do not know of any evidence whatsoever for a supposed
split between the tiny VPython community and the huge Python community
concerning floating point variables. Nor do I see anything in Python
On 1/13/2013 5:49 AM, Nick Coghlan wrote:
I agree it makes it obvious what the right default behaviour should
be: flag every FD as sensitive by default, and pass an argument to say
sensitive=False when you want to disable Python's automatic
protections.
sensitive is a bad name... because the
Since this was copied to the Python-Dev list, I want to go on record as
stating firmly that there is no evidence whatsoever to substantiate claims
that there has ever been some kind of conflict between VPython and Python.
My apologies, Bruce, I didn't mean for that second message to go to
they
22 matches
Mail list logo
