On Sat, Jan 26, 2013 at 12:54 AM, Victor Stinner
wrote:
> But do we really want to enable close-on-exec in the future? Charles
> François has really good arguments against such choice :-)
While many of Python's APIs are heavily inspired by POSIX, it still
isn't POSIX. It isn't C either, especiall
I created the following issue to track and review the implementation
of the PEP 433:
http://bugs.python.org/issue17036
Last changes:
- don't hold the GIL to ensure "atomicity" of the close-on-exec flag
- apply the default value of cloexec on all C functions
- sys.setdefaultcloexec() don't have
ACTIVITY SUMMARY (2013-01-18 - 2013-01-25)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3837 ( +8)
closed 24971 (+29)
total 28808 (+37)
Open issues wit
2013/1/25 Nick Coghlan :
> I just realised I could be converted to a +0 if the runtime time
> switch could only be used to set the global default as "cloexec=True"
> and couldn't be used to switch it back again (for testing purposes, if
> you only want to switch it on temporarily, use a subprocess)
On Fri, Jan 25, 2013 at 10:07 PM, Nick Coghlan wrote:
> On Fri, Jan 25, 2013 at 9:36 PM, Antoine Pitrou wrote:
>> Le Fri, 25 Jan 2013 12:28:10 +0100,
>> Victor Stinner a écrit :
>>> Well, I don't know if sys.setdefaultcloexec() is a good idea or
>>> not :-)
>>
>> Both Charles-François and Nick h
On Fri, Jan 25, 2013 at 9:36 PM, Antoine Pitrou wrote:
> Le Fri, 25 Jan 2013 12:28:10 +0100,
> Victor Stinner a écrit :
>> > I think the default behaviour needs to be configurable from the
>> > environment and the command line, but I don't believe it should be
>> > configurable from within the in
Le Fri, 25 Jan 2013 12:28:10 +0100,
Victor Stinner a écrit :
> > I think the default behaviour needs to be configurable from the
> > environment and the command line, but I don't believe it should be
> > configurable from within the interpreter.
>
> sys.setdefaultcloexec() is convinient for unit
> I think the default behaviour needs to be configurable from the
> environment and the command line, but I don't believe it should be
> configurable from within the interpreter.
sys.setdefaultcloexec() is convinient for unit test, but it may also
be used by modules. A web framework may want to en
2013/1/25 Charles-François Natali :
> You can actually count me in the cloexec=False camp, and against the
> idea of a configurable default value.
Oh ok.
> Why cloexec shouldn't be set by default:
> - While it's really tempting to fix one of Unix historical worst
> decisions, I don't think we can
On Fri, Jan 25, 2013 at 6:56 PM, Charles-François Natali
wrote:
> Hello,
>
>> I tried to list in the PEP 433 advantages and drawbacks of each option.
>>
>> If I recorded correctly opinions, the different options have the
>> following supporters:
>>
>> a) cloexec=False by default
>> b) cloexec=Tr
Hello,
> I tried to list in the PEP 433 advantages and drawbacks of each option.
>
> If I recorded correctly opinions, the different options have the
> following supporters:
>
> a) cloexec=False by default
> b) cloexec=True by default: Charles-François Natali
> c) configurable default value: An
11 matches
Mail list logo
