user what they want first if there's unsaved stuff, and may cancel).
It closes more than before.
Add unload_extensions() method to unload all extensions; called from
_close(). It calls an extension's close() method if it has one.
1. Fix incorrect file open mode on Win32 platforms (use "rb" instead
of "r").
2. Add shallow parameter to cmp.cmp(). If false, deep file
comparisons are made.
The module should be 100 percent backwards compatible.
avoid being fooled into thinking that fcntl and FCNTL are the same
thing -- they aren't! (fcntl is the extension, FCNTL.py is h2py
output that defines all the constants).
(XXX The example is still weird -- I think there's a more portable way
to do locking now. That's for someone else to fix...)
Urllib makes the URL of the opened file available through the geturl
method of the returned object. For local files, this consists of
file: plus the name of the file. This results in an invalid URL if
the file name was relative. This patch fixes this so that the
returned URL is just a relative URL in that case. When the file name
is absolute, the URL returned is of the form file:///absolute/path.
[I guess that a URL of the form "file:foo.html" is illegal... GvR]
"""
When there are additional Setup files, specified by -e option of freeze,
checkextenstions.py assumes that *.o, *.a, -Lpath, and -Rpath are all
relative to where the Setup file is. select() inserts the path to the
Setup file to make them absolute. However, the assumption is not true.
There are cases that absolute paths are specified for them. The inserted
prefix, by select(), results in error.
The following fix check for absolute paths. The assumption is: an
absolute path begins with either '/' or '$'. In the latter case, it is
from the environmental variable. (Variables defined locally in the Setup
file have already been handled by expandvars())
"""
My version of the patch has been verified by Charles Waldman (a
colleague of Chih-Hao).
Introduce a new builtin exception, UnboundLocalError, raised when ceval.c
tries to retrieve or delete a local name that isn't bound to a value.
Currently raises NameError, which makes this behavior a FAQ since the same
error is raised for "missing" global names too: when the user has a global
of the same name as the unbound local, NameError makes no sense to them.
Even in the absence of shadowing, knowing whether a bogus name is local or
global is a real aid to quick understanding.
Example:
D:\src\PCbuild>type local.py
x = 42
def f():
print x
x = 13
return x
f()
D:\src\PCbuild>python local.py
Traceback (innermost last):
File "local.py", line 8, in ?
f()
File "local.py", line 4, in f
print x
UnboundLocalError: x
D:\src\PCbuild>
Note that UnboundLocalError is a subclass of NameError, for compatibility
with existing class-exception code that may be trying to catch this as a
NameError. Unfortunately, I see no way to make this wholly compatible
with -X (see comments in bltinmodule.c): under -X, [UnboundLocalError
is an alias for NameError --GvR].
[The ceval.c patch differs slightly from the second version that Tim
submitted; I decided not to raise UnboundLocalError for DELETE_NAME,
only for DELETE_LOCAL. DELETE_NAME is only generated at the module
level, and since at that level a NameError is raised for referencing
an undefined name, it should also be raised for deleting one.]
Toby writes:
winmakemakefile.py tries to allow for spaces in the python install
path, by adding quotes around the appropriate filenames. It doesn't
quite get this correct; sometimes the quotes end up in the middle of
the path.
Microsoft's NMAKE version 6.0 is happy with this (!!!!) unless there
is also a space in the name. I guess most users of freeze on windows
do not use the same path as the binary distribution.
I've tested the following changes on systems with and without a space
in the path.
lots of markup fixes and some English nits fixed.
Still needs real review. Some of the function signatures used in this
module are really bad! (Two leading optional parameters? Ugh!)
We occasionally received reports from people getting "invalid tstate"
crashes (this is a fatal error in PyThreadState_Delete()). Finally
several people were able to reproduce it reliably and Tim Peters
discovered that there is a race condition when multiple threads are
calling this function without holding the global interpreter lock (the
function may be called without holding that).
Solved the race condition by adding a lock around the mutating uses of
interp->tstate_head. Tim and Jonathan Giddy have run tests that make
it likely that this fixes the crashes -- although Tim hasn't heard
from the person who reported the original problem.
Guido van Rossum