class from the standard base exception Exception. Otherwise define
Queue.Empty as a string exception.
(Queue): 8-space to 4-space indentation conversion. Also, basically
recast all method comments into docstrings.
Makefile: Add dependency on libqueue.tex
lib.tex: Place the libqueue.tex documentation just after libthread.tex
since Queue depends on thread support in Python.
format(), str(), atof(), and atoi(). The last three are locale
sensitive versions of the corresponding standard functions (only for
numbers though); format() does general %[efg] formatting taking the
locale into account, optionally with thousands grouping.
This is a bit of a hack: when the shared library is loaded, the module
name is "package.module", but the module calls Py_InitModule*() with just
"module" for the name. The shared library loader squirrels away the true
name of the module in _Py_PackageContext, and Py_InitModule*() will
substitute this (if the name actually matches).
1) The __builtins__ variable in the __main__ module is set to the
__builtin__ module instead of its __dict__.
2) Get rid of the SIGHUP and SIGTERM handlers. They can't be made to
work reliably when threads may be in use, they are Unix specific, and
Python programmers can now program this functionality is a safer way
using the signal module.
PyNumber_Coerce() except that when the coercion can't be done and no
other exceptions happen, it returns 1 instead of raising an
exception.
Use this function in PyObject_Compare() to avoid raising an exception
simply because two objects with numeric behavior can't be coerced to a
common type; instead, proceed with the non-numeric default comparison.
Note that this is a somewhat questionable practice -- comparisons for
numeric objects shouldn't default to random behavior like this, but it
is required for backward compatibility. (Case in point, it broke
comparison of kjDict objects to integers in Aaron Watters' kjbuckets
extension.) A correct fix (for python 2.0) should involve a different
definiton of comparison altogether.
signal handlers in a fork()ed child process when Python is compiled with
thread support. The bug was reported by Scott <scott@chronis.icgroup.com>.
What happens is that after a fork(), the variables used by the signal
module to determine whether this is the main thread or not are bogus,
and it decides that no thread is the main thread, so no signals will
be delivered.
The solution is the addition of PyOS_AfterFork(), which fixes the signal
module's variables. A dummy version of the function is present in the
intrcheck.c source file which is linked when the signal module is not
used.
in a few places -- so it can be set to .exe on GNUWIN32 platforms and
do the right thing. Whatever. (This was already done in
Modules/Makefile* but wasn't carried over here.)
All geometry manager methods that apply to a master widget instead of
to a slave widget have been moved to the Misc class, which is
inherited by all of Tk(), Toplevel() and Widget(). They have been
renamed to have their geometry manager name as a prefix,
e.g. pack_propagate(); the short names can still be used where
ambiguities are resolved so that pack has priority over place has
priority over grid (since this was the old rule).
Also, the method definitions in the Pack, Place and Grid classes now
all have their respective geometry manager name as a prefix
(e.g. pack_configure); the shorter names are aliases defined through
assignment.
A similar renaming has been done for all config() methods found
elsewhere; these have been renamed to configure() with config being
the alias (instead of the other way around). (This may not make much
of a difference but the official Tk command name is now 'configure'
and it may help in debugging tracebacks.)
Finally, a new base class BaseWidget has been introduced, which
implements the methods common between Widget and Toplevel (the
difference between those two classes is that Toplevel has a different
__init__() but also that Toplevel doesn't inherit from Pack, Place or
Grid.
sys.stdin.readline(), you get a fatal error (no current thread). This
is because there was a call to PyErr_CheckSignals() while there was no
current thread. I wonder how many more of these we find... I bnetter
go hunting for PyErr_CheckSignals() now...
Guido van Rossum
Barry Warsaw