popen2.popen2/3/4 functions can be a sequence. All texts are a variation on the
following:
On \UNIX, \var{cmd} may be a sequence, in which case arguments will be passed
directly to the program without shell intervention (as with
\function{os.spawnv()}). If \var{cmd} is a string it will be passed to the shell
(as with \function{os.system()}).
Clarifed that os.environ is captured once; emphasized that it's better
to assign to os.environ than to call putenv() directly (the putenv()
docs said so, but the environ docs didn't).
A LaTeX comment identified the 6 os.O_XXX constants the docs claimed
are available on Windows but aren't. The bug report listed the same 6.
Split these non-Windows constants into a different table with a possibly
correct "Availability:" claim.
tmpnam() appears essentially useless on Windows, and it finally broke
the test for Irmen de Jong. Read the long new comment in test_tmpnam()
for details. Since the MS implementation is insane, it might be good
if we supplied a different implementation.
Bugfix candidate.
docs here are best-guess: the MS docs I could find weren't clear, and
some even claimed _commit() has no effect on Win32 systems (which is
easily shown to be false just by trying it).
- Implement the behavior as specified in PEP 277, meaning os.listdir()
will only return unicode strings if it is _called_ with a unicode
argument.
- And then return only unicode, don't attempt to convert to ASCII.
- Don't switch on Py_FileSystemDefaultEncoding, but simply use the
default encoding if Py_FileSystemDefaultEncoding is NULL. This means
os.listdir() can now raise UnicodeDecodeError if the default encoding
can't represent the directory entry. (This seems better than silcencing
the error and fall back to a byte string.)
- Attempted to decribe the above in Doc/lib/libos.tex.
- Reworded the Misc/NEWS items to reflect the current situation.
This checkin also fixes bug #696261, which was due to os.listdir() not
using Py_FileSystemDefaultEncoding, like all file system calls are
supposed to.