2013/1/8 Victor Stinner :
> 2013/1/8 Benjamin Peterson :
>> 2013/1/8 Victor Stinner :
>>> 2013/1/8 Benjamin Peterson :
Okay, fair enough, but I really would like it not to ever raise
NotImplementedError. Then you would end up having different codepaths
for various oses anyway.
>>>
>>
2013/1/8 Benjamin Peterson :
> 2013/1/8 Victor Stinner :
>> 2013/1/8 Benjamin Peterson :
>>> Okay, fair enough, but I really would like it not to ever raise
>>> NotImplementedError. Then you would end up having different codepaths
>>> for various oses anyway.
>>
>> So what do you suggest?
>
> If th
2013/1/8 Victor Stinner :
> 2013/1/8 Benjamin Peterson :
>> Okay, fair enough, but I really would like it not to ever raise
>> NotImplementedError. Then you would end up having different codepaths
>> for various oses anyway.
>
> So what do you suggest?
If the only systems it doesn't work on is anc
2013/1/8 Benjamin Peterson :
> Okay, fair enough, but I really would like it not to ever raise
> NotImplementedError. Then you would end up having different codepaths
> for various oses anyway.
So what do you suggest?
Victor
___
Python-Dev mailing list
2013/1/8 Victor Stinner :
> Oops, I sent my email too early by mistake (it was not finished).
>
>> The myriad cloexec
>> APIs between different platforms suggests to me that using this
>> features requires understanding its various quirks on different
>> platforms.
>
> Sorry, I don't understand. Wh
2013/1/8 Victor Stinner :
> I don't know platform without this flag.
According to the following email, fcntl.FD_CLOEXEC was not available
in Python 2.2 on Red Hat 7.3 (in 2003):
http://communities.mentor.com/community/cs/archives/qmtest/msg00501.html
I don't know if the constant was not defined i
Oops, I sent my email too early by mistake (it was not finished).
> The myriad cloexec
> APIs between different platforms suggests to me that using this
> features requires understanding its various quirks on different
> platforms.
Sorry, I don't understand. What do you mean by "various quirks".
Benjamin wrote:
> I'm not sure it's worth cluttering the open() interface with such a
> non-portable option.
Zbyszek wrote:
> If the best-effort fallback is included, it is quite portable. Definitely
> all modern and semi-modern systems support either the atomic or the
> nonatomic methods.
Gregory
On Mon, Jan 7, 2013 at 4:03 PM, Benjamin Peterson wrote:
> 2013/1/7 Victor Stinner :
> > Hi,
> >
> > I would like add a new flag to open() mode to close the file on exec:
> > "e". This feature exists using different APIs depending on the OS and
> > OS version: O_CLOEXEC, FD_CLOEXEC and O_NOINHERIT
On Mon, Jan 07, 2013 at 06:03:54PM -0600, Benjamin Peterson wrote:
> 2013/1/7 Victor Stinner :
> > Hi,
> >
> > I would like add a new flag to open() mode to close the file on exec:
> > "e". This feature exists using different APIs depending on the OS and
> > OS version: O_CLOEXEC, FD_CLOEXEC and O_
2013/1/7 Gregory P. Smith :
>
>
>
> On Mon, Jan 7, 2013 at 4:03 PM, Benjamin Peterson
> wrote:
>>
>> 2013/1/7 Victor Stinner :
>> > Hi,
>> >
>> > I would like add a new flag to open() mode to close the file on exec:
>> > "e". This feature exists using different APIs depending on the OS and
>> > OS
2013/1/7 Victor Stinner :
> Hi,
>
> I would like add a new flag to open() mode to close the file on exec:
> "e". This feature exists using different APIs depending on the OS and
> OS version: O_CLOEXEC, FD_CLOEXEC and O_NOINHERIT. Do you consider
> that such flag would be interesting?
I'm not sure
Hi,
I would like add a new flag to open() mode to close the file on exec:
"e". This feature exists using different APIs depending on the OS and
OS version: O_CLOEXEC, FD_CLOEXEC and O_NOINHERIT. Do you consider
that such flag would be interesting?
On Linux (glibc), the feature is available as the
13 matches
Mail list logo
