> 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
th
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 th
On Sun, Jan 13, 2013 at 12:14 PM, Bruce Sherwood
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 that
> needs to be "fi
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.
I
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
On Sun, Jan 13, 2013 at 7:31 AM, Serhiy Storchaka wrote:
> 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 better place to
On Sun, Jan 13, 2013 at 1:15 AM, Bruce Sherwood 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 an
> unavoidable "fea
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
http://mail.python.org/mailman/listin
On 13.01.13 16:28, eli.bendersky wrote:
http://hg.python.org/cpython/rev/f0e80c7404a5
changeset: 81490:f0e80c7404a5
user:Eli Bendersky
date:Sun Jan 13 06:27:51 2013 -0800
summary:
Cleanup the docs ElementTree a bit and describe the default_namespace
parameter. In the code,
> 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 fla
On Sun, 13 Jan 2013 23:49:32 +1000
Nick Coghlan 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 let us even
On Sun, Jan 13, 2013 at 11:22 PM, Antoine Pitrou wrote:
> On Sun, 13 Jan 2013 22:44:06 +1000
> Nick Coghlan wrote:
>> On Sun, Jan 13, 2013 at 9:43 PM, Antoine Pitrou wrote:
>> > As for the opacity, feel free to propose something better
>> > ("close_on_spawn", whatever). But I'm definitely and st
On Sun, 13 Jan 2013 22:44:06 +1000
Nick Coghlan wrote:
> On Sun, Jan 13, 2013 at 9:43 PM, Antoine Pitrou 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 quit
On Sun, Jan 13, 2013 at 9:43 PM, Antoine Pitrou 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 the user s
On Sun, 13 Jan 2013 21:33:30 +1000
Nick Coghlan wrote:
> On Sun, Jan 13, 2013 at 9:15 PM, Antoine Pitrou 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
On Sun, Jan 13, 2013 at 9:15 PM, Antoine Pitrou 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 exec(), *not
On Sun, 13 Jan 2013 21:13:42 +1000
Nick Coghlan 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 coming
On Sun, Jan 13, 2013 at 8:40 PM, Charles-François Natali
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 in the
> chil
On Sun, Jan 13, 2013 at 8:40 PM, Charles-François Natali
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
> definition/
On Sun, Jan 13, 2013 at 2:40 AM, Charles-François Natali
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
> definition/
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 P
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
date:Sat Jan 12 07:44:32 2013 -0800
summary:
clean trailing whitespace
Can you please cle
22 matches
Mail list logo
