module: the piped streams can now be properly read from or written to.
(this was broken due to the 2.x to 3.x transition; communicate() support
is still sketchy)
Mac OS X adds __CF_USER_TEXT_ENCODING variable to an empty environment. Fix
also the test on the Py_ENABLE_SHARED config varible: test that the variable is
present, don't check it's value.
Mac OS X adds __CF_USER_TEXT_ENCODING variable to an empty environment. Fix
also the test on the Py_ENABLE_SHARED config varible: test that the variable is
present, don't check it's value.
shared mode
Try also to get more informations about the Mac OS X failure: display the keys
of the environment, instead of just the number of variables.
the file descriptor of a pipe closed in the parent process is valid in the
child process according to fstat(), but the mode of the file descriptor is
invalid, and read or write raise an error.
test.support.requires_mac_ver() is now a decorator, as suggested by Ezio
Melotti, and its docstring is fixed (linux_version => mac_ver).
descriptor of a pipe closed in the parent process is valid in the child process
according to fstat(), but the mode of the file descriptor is invalid, and read
or write raise an error.
Add also requires_mac_ver() decorator to test.support.
Remove the pure Python POSIX subprocess implementation.
If non-CPython VMs (are there any for 3.x yet?) were somehow depending
on this, they already have the exact same set of problems with Python
code being executed after os.fork() that _posixsubprocess was written
to deal with. They should implement an equivalent outside of Python.
_posixsubprocess doesn't exist rather than simply stubbing it out
after the fact. This adds coverage for the RuntimeWarning as well as
using the pure python _create_pipe instead of using
_posixsubprocess.cloexec_pipe unintentionally with the pure python
code.
Ironically: I don't think any platform should ever actually _use_ the
pure Python subprocess code on POSIX platforms anymore. This at least
tests it properly in this stable branch. The pure python code for
this is likely to be removed in 3.3.
_posixsubprocess doesn't exist rather than simply stubbing it out
after the fact. This adds coverage for the RuntimeWarning as well as
using the pure python _create_pipe instead of using
_posixsubprocess.cloexec_pipe unintentionally with the pure python
code.
Ironically: I don't think any platform should ever actually _use_ the
pure Python subprocess code on POSIX platforms anymore. This at least
tests it properly in this stable branch. The pure python code for
this is likely to be removed in 3.3.