The test suite fetches the C recursion limit from the _testcapi
extension module. Test extension modules can be disabled using the
--disable-test-modules configure option.
Symbols of the C API should be prefixed by "Py_" to avoid conflict
with existing names in 3rd party C extensions on "#include <Python.h>".
test.pythoninfo now logs Py_C_RECURSION_LIMIT constant and other
_testcapi and _testinternalcapi constants.
In test_fromkeys() the derived test class now supports all arguments in its
constructor so that the class to be tested can use its own constructor in its
fromkeys() implementation.
In test_mutatingiteration() the test fails as soon as iterating over a
dictionary with one entry and adding new entries in the loop iterates more
than once (to avoid endless loops in faulty implementations).
https://bugs.python.org/issue2661
in order to make algorithmic complexity attacks on (e.g.) web apps much more complicated.
The environment variable PYTHONHASHSEED and the new command line flag -R control this
behavior.
in order to make algorithmic complexity attacks on (e.g.) web apps much more complicated.
The environment variable PYTHONHASHSEED and the new command line flag -R control this
behavior.
Clearly this is not the right way to fix this; UserDict and MixinDict
ought to be redesigned with the new dict API in mind. But I'm not
claiming to be in charge of library redesign, I only want zero failing
tests.
and .keys(), .items(), .values() return dict views.
The dict views aren't fully functional yet; in particular, they can't
be compared to sets yet. but they are useful as "iterator wells".
There are still 27 failing unit tests; I expect that many of these
have fairly trivial fixes, but there are so many, I could use help.
*ordering* between objects; there is only a default equality test
(defined by an object being equal to itself only). Read the comment
in object.c. The current implementation never uses a three-way
comparison to compute a rich comparison, but it does use a rich
comparison to compute a three-way comparison. I'm not quite done
ripping out all the calls to PyObject_Compare/Cmp, or replacing
tp_compare implementations with tp_richcompare implementations;
but much of that has happened (to make most unit tests pass).
The following tests still fail, because I need help deciding
or understanding:
test_codeop -- depends on comparing code objects
test_datetime -- need Tim Peters' opinion
test_marshal -- depends on comparing code objects
test_mutants -- need help understanding it
The problem with test_codeop and test_marshal is this: these tests
compare two different code objects and expect them to be equal.
Is that still a feature we'd like to support? I've temporarily
removed the comparison and hash code from code objects, so they
use the default (equality by pointer only) comparison.
For the other two tests, run them to see for yourself.
(There may be more failing test with "-u all".)
A general problem with getting lots of these tests to pass is
the reality that for object types that have a natural total ordering,
implementing __cmp__ is much more convenient than implementing
__eq__, __ne__, __lt__, and so on. Should we go back to allowing
__cmp__ to provide a total ordering? Should we provide some other
way to implement rich comparison with a single method override?
Alex proposed a __key__() method; I've considered a __richcmp__()
method. Or perhaps __cmp__() just shouldn't be killed off...
Not all code has been fixed yet; this is just a checkpoint...
The C API still has PyDict_HasKey() and _HasKeyString(); not sure
if I want to change those just yet.
mapping tests as possible in mapping_test.py and reuse the tests in
test_dict.py, test_userdict.py, test_weakref.py, test_os.py and test_shelve.py.
From SF patch #736962.
Erlend E. Aasland
Alex Waygood
Victor Stinner
Mark Shannon
Walter Dörwald
Serhiy Storchaka
Georg Brandl
Ezio Melotti
Mark Dickinson
Benjamin Peterson
Raymond Hettinger
Brett Cannon
Guido van Rossum