On Tue, Jan 29, 2013 at 4:13 PM, Charles-François Natali
wrote:
> So I'm definitely -1 against any form of tunable value (be it a
> sys.setdefaultcloexec(), an environment variable or command-line
> flag), and still against changing the default value.
I now think the conservative option is to ini
Le Tue, 29 Jan 2013 11:24:49 +0100,
Ralf Schmitt a écrit :
> Please just acknowledge that having a global configurable setting may
> lead to problems.
Ralf, I won't "acknowledge" anything just so that it makes you
feel better. Your point has been made and has also been rebutted.
Let's agree to di
Antoine Pitrou writes:
> Le Tue, 29 Jan 2013 09:35:40 +0100,
> Ralf Schmitt a écrit :
>>
>> I'd rather not have to check if some library messes with that global
>> setting and work around it if it does!
>
> Then just don't try changing the flag. Problem solved.
I was talking about some library
Le Tue, 29 Jan 2013 09:35:40 +0100,
Ralf Schmitt a écrit :
> Antoine Pitrou writes:
>
> > Yes, it's fine, because an application developer can often control
> > (or at least study) the behaviour of all the code involved.
>
> I'd rather not have to check if some library messes with that global
>
Antoine Pitrou writes:
> Yes, it's fine, because an application developer can often control (or
> at least study) the behaviour of all the code involved.
I'd rather not have to check if some library messes with that global
setting and work around it if it does! The fact that you can control and
> Library code should not be relying on globals settings that can change.
Did you try my implementation of the PEP 433 on your project? Did you
review my patch implementing the PEP 433?
http://hg.python.org/features/pep-433
http://bugs.python.org/issue17036
I expected more change, whereas only ve
On Tue, 29 Jan 2013 01:17:35 +0100
Ralf Schmitt wrote:
> Guido van Rossum writes:
>
> >
> > On Mon, Jan 28, 2013 at 1:56 PM, Ralf Schmitt wrote:
> >
> >> Guido van Rossum writes:
> >>
> >> > Yeah, so the answer to all this is that 3rd party libraries know better
> >> > than to mess with global
> Library code should not be relying on globals settings that can change.
> Library code should be explicit in its calls so that the current value of a
> global setting is irrelevant.
That's one of the problems I've raised with this global flag since the
beginning: it's useless for libraries, incl
On 01/28/2013 04:17 PM, Ralf Schmitt wrote:
Guido van Rossum writes:
On Mon, Jan 28, 2013 at 1:56 PM, Ralf Schmitt wrote:
Guido van Rossum writes:
Yeah, so the answer to all this is that 3rd party libraries know better
than to mess with global settings.
Right. But why make it configurabl
Guido van Rossum writes:
>
> On Mon, Jan 28, 2013 at 1:56 PM, Ralf Schmitt wrote:
>
>> Guido van Rossum writes:
>>
>> > Yeah, so the answer to all this is that 3rd party libraries know better
>> > than to mess with global settings.
>>
>> Right. But why make it configurable at runtime then? If y
Sigh. This is getting exasperating. There's other code that might want to
change this besides 3rd party library code. E.g. app configuration code.
On Mon, Jan 28, 2013 at 1:56 PM, Ralf Schmitt wrote:
> Guido van Rossum writes:
>
> > Yeah, so the answer to all this is that 3rd party libraries kn
Guido van Rossum writes:
> Yeah, so the answer to all this is that 3rd party libraries know better
> than to mess with global settings.
Right. But why make it configurable at runtime then? If you're changing
the value, then you're the one probably breaking third party code.
_
"R. David Murray" writes:
> On Sun, 27 Jan 2013 21:56:06 +0100, Ralf Schmitt wrote:
>> "R. David Murray" writes:
>>
>> > On Sun, 27 Jan 2013 19:42:59 +0100, Ralf Schmitt
>> > wrote:
>> >> Guido van Rossum writes:
>> >>
>> >> > It's like calling socket.settimeout(0.1) and then complaining t
Yeah, so the answer to all this is that 3rd party libraries know better
than to mess with global settings.
On Mon, Jan 28, 2013 at 1:27 PM, Ralf Schmitt wrote:
> "R. David Murray" writes:
>
> > On Sun, 27 Jan 2013 21:56:06 +0100, Ralf Schmitt
> wrote:
> >> "R. David Murray" writes:
> >>
> >>
"R. David Murray" writes:
> On Sun, 27 Jan 2013 21:56:06 +0100, Ralf Schmitt wrote:
>> "R. David Murray" writes:
>>
>> > On Sun, 27 Jan 2013 19:42:59 +0100, Ralf Schmitt
>> > wrote:
>> >> Guido van Rossum writes:
>> >>
>> >> > It's like calling socket.settimeout(0.1) and then complaining t
On Sun, 27 Jan 2013 21:56:06 +0100, Ralf Schmitt wrote:
> "R. David Murray" writes:
>
> > On Sun, 27 Jan 2013 19:42:59 +0100, Ralf Schmitt wrote:
> >> Guido van Rossum writes:
> >>
> >> > It's like calling socket.settimeout(0.1) and then complaining that
> >> > urllib.urlopen() raises excepti
"R. David Murray" writes:
> On Sun, 27 Jan 2013 19:42:59 +0100, Ralf Schmitt wrote:
>> Guido van Rossum writes:
>>
>> > It's like calling socket.settimeout(0.1) and then complaining that
>> > urllib.urlopen() raises exceptions
>>
>> but that's not what's happening. you'll see urllib.urlopen r
On Sun, 27 Jan 2013 19:42:59 +0100, Ralf Schmitt wrote:
> Guido van Rossum writes:
>
> > It's like calling socket.settimeout(0.1) and then complaining that
> > urllib.urlopen() raises exceptions
>
> but that's not what's happening. you'll see urllib.urlopen raising
> exceptions and only afterwa
Guido van Rossum writes:
> It's like calling socket.settimeout(0.1) and then complaining that
> urllib.urlopen() raises exceptions
but that's not what's happening. you'll see urllib.urlopen raising
exceptions and only afterwards realize that you called into some third
party library code that dec
On Sun, Jan 27, 2013 at 3:45 AM, Nick Coghlan wrote:
> On Sun, Jan 27, 2013 at 9:29 PM, Antoine Pitrou wrote:
>> I don't think such limitations are very useful in practice. Users
>> calling sys.setdefaultexec() will have to be sufficiently knowledgeable
>> to understand the implications, anyway.
On Sun, Jan 27, 2013 at 9:29 PM, Antoine Pitrou wrote:
> I don't think such limitations are very useful in practice. Users
> calling sys.setdefaultexec() will have to be sufficiently knowledgeable
> to understand the implications, anyway.
I've yet to hear a use case for being able to turn it off
On Sun, 27 Jan 2013 12:23:15 +0100
Victor Stinner wrote:
> 2013/1/27 Guido van Rossum :
> > I had missed this detail. I agree that it should be exposed in the
> > interpreter. To my mind it is more like PYTHONPATH (which corresponds
> > roughly to sys.path manipulations) than like -R (which change
2013/1/27 Guido van Rossum :
> I had missed this detail. I agree that it should be exposed in the
> interpreter. To my mind it is more like PYTHONPATH (which corresponds
> roughly to sys.path manipulations) than like -R (which changes
> something that should never be changed again, otherwise the sa
On Sat, Jan 26, 2013 at 8:48 PM, Cameron Simpson wrote:
> On 25Jan2013 21:07, Nick Coghlan wrote:
> | It's a configurable setting in the same way that -Q makes the
> | behaviour of "/" configurable in Python 2 (so your hypothetical
> | example isn't hypothetical at all - it's a description the -Q
On 25Jan2013 21:07, Nick Coghlan wrote:
| It's a configurable setting in the same way that -Q makes the
| behaviour of "/" configurable in Python 2 (so your hypothetical
| example isn't hypothetical at all - it's a description the -Q option),
| and -R makes random hashing configurable in 2.7 and 3
On 25Jan2013 12:24, Victor Stinner wrote:
| 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.
I'm leaning to this view myself also.
| > Why the default value shouldn't be tunable:
| >
> So, if we agree that "cloexec-by-default" is a desirable goal, despite
> the inconsistency with POSIX (just as changing integer division was
> seen as desirable, despite the inconsistency with C) ...
I don't plan to enable cloexec by default in a near future, nor in python
4. Someone else may ch
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
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
Hi,
The PEP 433 proposes different options to add a new cloexec parameter:
a) cloexec=False by default
b) cloexec=True by default
c) configurable default value
I tried to list in the PEP 433 advantages and drawbacks of each option.
If I recorded correctly opinions, the different options have
37 matches
Mail list logo
