Weak*Dictionary.update(): No longer create a temporary list to hold the
things that will be stuffed into the underlying dictionary. This had
been done so that if any of the objects used as the weakly-held value
was not weakly-referencable, no updates would take place (TypeError
would be raised). With this change, TypeError will still be raised
but a partial update could occur. This is more like other .update()
implementations.
Thoughout, use of the name "ref" as a local variable has been removed. The
original use of the name occurred when the function to create a weak
reference was called "new"; the overloaded use of the name could be
confusing for someone reading the code. "ref" used as a variable name
has been replaced with "wr" (for 'weak reference').
(Note that the docs are also being maintained on the 2.1.1 maintenance
branch, so users interested only in corrections and clarifications
can get that.)
(Note that the docs are also being maintained on the 2.1.1 maintenance
branch, so users interested only in corrections and clarifications
can get that.)
variables reported by PyChecker.
__togglegentype(): PyChecker accurately reported that the variable
__gentypevar was unused -- actually this whole method is currently
unused so comment it out.
macro.
Refactored do_cmd_versionadded() and do_cmd_versionchanged() to do most
of the work in a helper function, with the do_cmd_*() wrappers just supplying
a portion of the replacement text.
The changes cause compilation failures in any file in the Python
installation lib directory to cause the install to fail. It looks
like compileall.py intended to behave this way, but a change to
py_compile.py and a separate bug defeated it.
Fixes SF bug #412436
This change affects the test suite, which contains several files that
contain intentional errors. The solution is to extend compileall.py
with the ability to skip compilation of selected files.
NB compileall.py is changed so that compile_dir() returns success only
if all recursive calls to compile_dir() also check success.
The changes cause compilation failures in any file in the Python
installation lib directory to cause the install to fail. It looks
like compileall.py intended to behave this way, but a change to
py_compile.py and a separate bug defeated it.
Fixes SF bug #412436
This change affects the test suite, which contains several files that
contain intentional errors. The solution is to extend compileall.py
with the ability to skip compilation of selected files.
In the test suite, rename nocaret.py and test_future[3..7].py to start
with badsyntax_nocaret.py and badsyntax_future[3..7].py. Update the
makefile to skip compilation of these files. Update the tests to use
the name names for imports.
NB compileall.py is changed so that compile_dir() returns success only
if all recursive calls to compile_dir() also check success.
file was deleted by a previous call to the visitor function.
This used to be the behavior in 1.5.2 and before, but a patch to avoid
making two stat() calls accidentally broke this in 2.0.
Moshe, this would be a good one for 2.0.1 too!
its first return statement returns a single value while its caller
always expects it to return a tuple of two items. Fix this by
returning (s, 0) instead.
This won't make the locale test on Irix succeed, but now it will fail
because of a bug in the platform's en_US locale rather than because of
a bug in the locale module.
than from module pickletester. Using the latter turned out to cause
the test to break when invoked as "import test.test_pickle" or "import
test.autotest".
OpenSSL versions beore 0.9.5. This just is too experimental to be
worth it, especially since the user would have to do some severe
hacking of the Modules/Setup file to even enable the EGD code, and
without the EGD code it would always spit out a warning on some
systems -- even when socket.ssl() is not used. Fixing that properly
is not my job; the EGD patch is clearly not so important that it
should hold up the 2.1 release.
PyTuple_New() could *conceivably* clear the dict, so move the test for
an empty dict after the tuple allocation. It means that we waste time
allocating and deallocating a 2-tuple when the dict is empty, but who
cares. It also means that when the dict is empty *and* there's no
memory to allocate a 2-tuple, we raise MemoryError, not KeyError --
but that may actually a good idea: if there's no room for a lousy
2-tuple, what are the chances that there's room for a KeyError
instance?
and reported to python-dev: because we were calling dict_resize() in
PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(),
and because PyTuple_New() can cause GC, and because dict_items() calls
PyTuple_New(), it was possible for dict_items() to have the dict
resized right under its nose.
The solution is convoluted, and touches several places: keys(),
values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem().
There are two parts to it. First, we no longer call dict_resize() in
PyDict_Next(), which seems to solve the immediate problem. But then
PyDict_SetItem() must have a different policy about when *it* calls
dict_resize(), because we want to guarantee (e.g. for an algorithm
that Jeremy uses in the compiler) that you can loop over a dict using
PyDict_Next() and make changes to the dict as long as those changes
are only value replacements for existing keys using PyDict_SetItem().
This is done by resizing *after* the insertion instead of before, and
by remembering the size before we insert the item, and if the size is
still the same, we don't bother to even check if we might need to
resize. An additional detail is that if the dict starts out empty, we
must still resize it before the insertion.
That was the first part. :-)
The second part is to make keys(), values(), items(), and popitem()
safe against side effects on the dict caused by allocations, under the
assumption that if the GC can cause arbitrary Python code to run, it
can cause other threads to run, and it's not inconceivable that our
dict could be resized -- it would be insane to write code that relies
on this, but not all code is sane.
Now, I have this nagging feeling that the loops in lookdict probably
are blissfully assuming that doing a simple key comparison does not
change the dict's size. This is not necessarily true (the keys could
be class instances after all). But that's a battle for another day.
Jeremy Hylton
Fred Drake
Tim Peters
Martin v. Löwis
Guido van Rossum
Barry Warsaw
Eric S. Raymond
cvs2svn
Andrew M. Kuchling
Fredrik Lundh