On Sun, Jun 24, 2007 at 10:48:30PM +0200, "Martin v. Löwis" wrote:
> >> I don't see why it is a requirement to *open* the file in
> >> non-inheritable mode. Why is not sufficient to *modify*
> >> an open file to have its handle non-inheritable in
> >> an easy and platform-independent way?
> >
> >
>> I don't see why it is a requirement to *open* the file in
>> non-inheritable mode. Why is not sufficient to *modify*
>> an open file to have its handle non-inheritable in
>> an easy and platform-independent way?
>
> Threads. Consider that you may fork a process on one thread right
> between the
On Jun 24, 2007, at 2:19 PM, Martin v. Löwis wrote:
> I don't see why it is a requirement to *open* the file in
> non-inheritable mode. Why is not sufficient to *modify*
> an open file to have its handle non-inheritable in
> an easy and platform-independent way?
Threads. Consider that you may for
>> Putting it into the library is fine. However, we need to find
>> an implementation strategy that meets the user's needs, and
>> is still maintainable.
>>
>> Python 3 will offer a clean solution, deviating entirely from
>> stdio.
>
> Let me point out that stdio is not the problem.
> The problem
Guido van Rossum schrieb:
> Those are valid concerns. I'm cross-posting this to the python-3000
> list in the hope that the PEP's author and defendents can respond. I'm
> sure we can work something out.
Another question w.r.t. new string formatting:
Assuming the %-operator for strings goes away a
"""
My very personal opinion:
After a sleepness night, it seems to me that this is not a Python problem
(or any other programming language at all).
It looks more like an OS design problem (on MS Windows as well as
on Linux etc). In an ideal world, when a program asks the OS to start
a child process
