[ 1232517 ] OverflowError in time.utime() causes strange traceback
A needed error check was missing.
(Actually, this error check may only have become necessary in fairly
recent Python, not sure).
Backport candidate.
with major C compilers (VACPP, EMX+gcc and [Open]Watcom).
Also tidy up the export of spawn*() symbols in the os module to match what
is found/implemented.
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).
string does what is expected (ie unset [BEGIN|END]LIBPATH)
- set the size of the DosQuerySysInfo buffer correctly; it was safe,
but incorrect (allowing a 1 element overrun)
- 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.
PyMapping_Check() doesn't guarantee that PyMapping_Size() won't raise
an exception, nor that keys and values are lists.
Also folded some long lines and did a little whitespace normalization.
Probably a 2.2 backport candidate.
us to completely decouple the framework from the executable, so we
can use a two-level namespace.
- Do framework builds with a twolevel namespace.
- Reorganized the code that creates the minimal framework in the build
directory, to make it more robust against incomplete frameworks (from
earlier aborted builds, or builds of previous Python versions).
Don't pass CREATE_NEW_CONSOLE to CreateProcess(), meaning our child process is in the same "console group" and therefore interrupted by the same Ctrl+C that interrupts the parent.
MSDN sample programs use it, apparently in error. The correct name
is WIN32_LEAN_AND_MEAN. After switching to the correct name, in two
cases more was needed because the code actually relied on things that
disappear when WIN32_LEAN_AND_MEAN is defined.
- Include a blank line between the signature line and the description
(Guido sez).
- Don't include "-> None" for API functions that always return None
because they don't have a meaningful return value.
and returns None. This allows any object that supports the fileno()
method to be passed as a file descriptor, not just an integer.
posix_fchdir(): New exposed function: implements posix.fchdir(). This
closes SF feature #536796.
posix_fsync(), posix_fdatasync(): Convert to use posix_fildes() instead
of posix_int(). This also changes them from METH_VARARGS to METH_O
functions.
setup_confname_table(): Remove unused variable. Change to take a module
rather than a dict to save the resulting table into.
setup_confname_tables(): Change to take a module instead of a dict to
pass to setup_confname_table().
457466: popenx() argument mangling hangs python
226766: popen('python -c"...."') tends to hang
Fixes argument quoting in w9xpopen.exe for Windows 9x. w9xpopen.exe
also never attempts to display a MessageBox when not executed
interactively.
Added test_popen() test. This test currently just executes
"python -c ..." as a child process, and checks that the expected
arguments were all recieved correctly by the child process. This
test succeeds for me on Win9x, win2k and Linux, and I hope it does
for other popen supported platforms too :)
over SEP, ALTSEP and MAXPATHLEN.
Patched up posixmodule.c for MSVC, but unsure what the story is now on
other non-Unixish platforms -- the preprocessor maze has no exit <wink>.
Modules/
posixmodule.c
- use SEP,ALTSEP #defines instead of hard coded path separator chars
- use EMX specific variants of chdir2(),getcwd() that support drive letters
- OS/2+EMX spawnv(),spawnve() support
- EMX specific popen[234]() derived from Win32 popen[234]() code
where their capabilities intersect. Would be nice if people using non-
MSVC compilers (Borland etc) took a whack at doing something similar for
them (this code relies on the MS _cwait function).
Patch from Mark Hammond, plus code rearrangement and comments from me.
posix_do_stat(): Windows-specific code could try to free() stack
memory in some cases when a path ending with a forward or backward slash
was passed to os.stat().
type.__module__ behavior.
This adds the module name and a dot in front of the type name in every
type object initializer, except for built-in types (and those that
already had this). Note that it touches lots of Mac modules -- I have
no way to test these but the changes look right. Apologies if they're
not. This also touches the weakref docs, which contains a sample type
object initializer. It also touches the mmap test output, because the
mmap type's repr is included in that output. It touches object.h to
put the correct description in a comment.
Anthony Roach.
Release the global interpreter lock around platform spawn calls.
Bugfix candidate? Hard to say; I favor "yes, bugfix".
These clearly *should* have been releasing the GIL all along, if for no
other reason than compatibility with the similar os.system(). But it's
possible some program out there is (a) multithreaded, (b) calling a spawn
function with P_WAIT, and (c) relying on the spawn call to block all their
threads until the spawned program completes. I think it's very unlikely
anyone is doing that on purpose, but someone may be doing so by accident.
This adds unsetenv to posix, and uses it in the __delitem__ method of
os.environ.
(XXX Should we change the preferred name for putenv to setenv, for
consistency?)
This is a big one, touching lots of files. Some of the platforms
aren't tested yet. Briefly, this changes the return value of the
os/posix functions stat(), fstat(), statvfs(), fstatvfs(), and the
time functions localtime(), gmtime(), and strptime() from tuples into
pseudo-sequences. When accessed as a sequence, they behave exactly as
before. But they also have attributes like st_mtime or tm_year. The
stat return value, moreover, has a few platform-specific attributes
that are not available through the sequence interface (because
everybody expects the sequence to have a fixed length, these couldn't
be added there). If your platform's struct stat doesn't define
st_blksize, st_blocks or st_rdev, they won't be accessible from Python
either.
(Still missing is a documentation update.)
Curious: the MS docs say stati64 etc are supported even on Win95, but
Win95 doesn't support a filesystem that allows partitions > 2 Gb.
test_largefile: This was opening its test file in text mode. I have no
idea how that worked under Win64, but it sure needs binary mode on Win98.
BTW, on Win98 test_largefile runs quickly (under a second).
pyport.h: typedef a new Py_intptr_t type.
DELICATE ASSUMPTION: That HAVE_UINTPTR_T implies intptr_t is
available as well as uintptr_t. If that turns out not to be
true, things must get uglier (C99 wants both, so I think it's
an assumption we're *likely* to get away with).
thread_nt.h, PyThread_start_new_thread: MS _beginthread is documented
as returning unsigned long; no idea why uintptr_t was being used.
Others: Always use Py_[u]intptr_t, never [u]intptr_t directly.
Also note that it isn't just Linux nice() that is broken: at least FreeBSD
and BSDI also have this problem. os.nice() should probably just be emulated
using getpriority()/setpriority(), if they are available, but I'll get to
that later.
"Partial" as the code uses sys.prefix in an attempt to locate 'w9xpopen.exe', but sys.prefix is not set if Python can't find it itself. So this _still_ fails in Pythonwin, but I am committing the patch for 2 reasons:
* Embedded apps that set sys.prefix or use PYTHONHOME will work
* The exception raised on failure to find the executable is far more obvious
subset of Win32 ShellExecute's functionality. Guido wants this because
IDLE's Help -> Docs function currently crashes his machine because of a
conflict between his version of Norton AntiVirus (6.10.20) and MS's
_popen. Docs for startfile are being mailed to Fred (or just read the
docstring -- it tells the whole story).
Changed webbrowser.py to use os.startfile instead of os.popen on Windows.
Changed IDLE's EditorWindow.py to pass an absolute path for the docs
(hardcoding ShellExecute's "directory" arg to "." as used to be done let
IDLE work, but made the startfile command exceedingly obscure for other
uses -- the MS docs are terrible, of course, & still not sure I
understand it).
Note that Windows Python must link with shell32.lib now! That's where
ShellExecute lives.
glob.glob("k:*py") (i.e., a raw drive letter + colon at the start) were
using the root of the drive rather than the expected Windows behavior
of using the drive's "current directory".
implementation. You don't want to know. I've asked Guido to give this
a critical review (we agreed on the approach, but the implementation
proved more ... interesting ... than anticipated). This will almost
certainly be the highlight of Mark Hammond's day <wink>.
Minor updates for BeOS R5.
Use of OSError in test.test_fork1 changed to TestSkipped, with corresponding
change in BeOS/README (by Fred).
This closes SourceForge patch #100978.
This is an enhancement to a prior patch (100941) ...
[T]his patch removes the risk of deadlock waiting for the child previously present in certain cases. It adds tracking of all file handles returned from an os.popen* call and only waits for the child process, returning the exit code, on the closure of the final file handle to that child.
for systems that are missing those declarations from system include files.
Start by moving a pointy-haired ones from their previous locations to the
new section.
(The gethostname() one, for instance, breaks on several systems, because
some define it as (char *, size_t) and some as (char *, int).)
I purposely decided not to include the summary of used #defines like Tim did
in the first section of pyport.h. In my opinion, the number of #defines
likedly to be used by this section would make such an overview unwieldy. I
would suggest documenting the non-obvious ones, though.
and a couple of functions that were missed in the previous batches. Not
terribly tested, but very carefully scrutinized, three times.
All these were found by the little findkrc.py that I posted to python-dev,
which means there might be more lurking. Cases such as this:
long
func(a, b)
long a;
long b; /* flagword */
{
and other cases where the last ; in the argument list isn't followed by a
newline and an opening curly bracket. Regexps to catch all are welcome, of
course ;)
comments, docstrings or error messages. I fixed two minor things in
test_winreg.py ("didn't" -> "Didn't" and "Didnt" -> "Didn't").
There is a minor style issue involved: Guido seems to have preferred English
grammar (behaviour, honour) in a couple places. This patch changes that to
American, which is the more prominent style in the source. I prefer English
myself, so if English is preferred, I'd be happy to supply a patch myself ;)
windows.
- added optional mode argument to popen2/popen3
for unix; if the second argument is an integer,
it's assumed to be the buffer size.
- changed nt.popen2/popen3/popen4 return values
to match the popen2 module (stdout first, not
stdin).
cast to make sure Py_BuildValue gets the right thing.
this change eliminates bogus return codes from successful
spawn calls (e.g. 2167387144924954624 instead of 0).
staring at the diffs before checking this one in. let me know
asap if it breaks things on your platform.
-- ANSI-fying
(patch #100763 by Peter Schneider-Kamp, minus the
indentation changes and minus the changes the broke
the windows build)
In posixmodule.c:posix_fork, the function PyOS_AfterFork is called for
both the parent and the child, despite the docs stating that it should
be called in the new (child) process.
This causes problems in the parent since the forking thread becomes the
main thread according to the signal module.
Calling PyOS_AfterFork() only in the child fixes this. Changed for both
fork() and forkpty().