The reference to copyreg was a unnoticed leftover from the compatibility
support for the grand renaming of the standard library in Python 3. The
compatibility support was reverted in r63493, but not completely as this
patch shows.
Based on a patch by Amaury Forgeot d'Arc.
If anyone wants to clean up the documentation, feel free. It's my first documentation foray, and it's not that great.
Will port to py3k with a different strategy.
does not return an iterator for the 4th and 5th items.
(sequence-like and mapping-like state)
A list is not an iterator...
Will backport to 2.6 and 2.5.
behaviours. I left the original test commented out (note
that that test came from #2702, which seems to have a
problem in FreeBSD and Windows, but not in Linux).
I included a new test, to watch over the now-broken
behaviour, I took it from #3179.
Added checks for integer overflows, contributed by Google. Some are
only available if asserts are left in the code, in cases where they
can't be triggered from Python code.
Renamed copy_reg to copyreg in the standard library, to avoid
spurious warnings and ease later merging to py3k branch. Public
documentation remains intact.
This code was broken if save() returned a negative number since i contained
a boolean value and then we compared i < 0 which should never be true.
Will backport (assuming it's necessary)
* unified the way intobject, longobject and mystrtoul handle
values around -sys.maxint-1.
* in general, trying to entierely avoid overflows in any computation
involving signed ints or longs is extremely involved. Fixed a few
simple cases where a compiler might be too clever (but that's all
guesswork).
* more overflow checks against bad data in marshal.c.
* 2.5 specific: fixed a number of places that were still confusing int
and Py_ssize_t. Some of them could potentially have caused
"real-world" breakage.
* list.pop(x): fixing overflow issues on x was messy. I just reverted
to PyArg_ParseTuple("n"), which does the right thing. (An obscure
test was trying to give a Decimal to list.pop()... doesn't make
sense any more IMHO)
* trying to write a few tests...
using a custom, nearly-identical macro. This probably changes how some of
these functions are compiled, which may result in fractionally slower (or
faster) execution. Considering the nature of traversal, visiting much of the
address space in unpredictable patterns, I'd argue the code readability and
maintainability is well worth it ;P
In C++, it's an error to pass a string literal to a char* function
without a const_cast(). Rather than require every C++ extension
module to put a cast around string literals, fix the API to state the
const-ness.
I focused on parts of the API where people usually pass literals:
PyArg_ParseTuple() and friends, Py_BuildValue(), PyMethodDef, the type
slots, etc. Predictably, there were a large set of functions that
needed to be fixed as a result of these changes. The most pervasive
change was to make the keyword args list passed to
PyArg_ParseTupleAndKewords() to be a const char *kwlist[].
One cast was required as a result of the changes: A type object
mallocs the memory for its tp_doc slot and later frees it.
PyTypeObject says that tp_doc is const char *; but if the type was
created by type_new(), we know it is safe to cast to char *.
Alexandre Vassalotti
Eric Smith
Neil Schemenauer
Amaury Forgeot d'Arc
Collin Winter
Antoine Pitrou
Mark Dickinson
Martin v. Löwis
Facundo Batista
Thomas Heller
Gregory P. Smith
Christian Heimes
Georg Brandl
Neal Norwitz
Kristján Valur Jónsson
Armin Rigo
Richard Jones
Thomas Wouters
Jeremy Hylton
Raymond Hettinger
Christian Tismer