The test function's signature should be
test(methodname, input, output, *args)
but the output argument was omitted. This caused all tests to fail,
because the expected output was passed as the initial argument to the
method call. But because of the way the test works (it compares the
results for a regular string to the results for a UserString instance
with the same value, and it's OK if both raise the same exception) the
test never failed!
I've fixed this, and also cleaned up a few warts in the verbose
output. Finally, I've made it possible to run the test stand-alone in
verbose mode by passing -v as a command line argument.
Now, the test will report failure related to zfill. That's not my
fault, that's a legitimate problem: the string_tests.py file contains
a test for the zfill() method (just added) but this method is not
implemented. The responsible party will surely fix this soon now.
non-us-ascii character sets in headers and bodies. Some API changes
(with DeprecationWarnings for the old APIs). Better RFC-compliant
implementations of base64 and quoted-printable.
Updated test cases. Documentation updates to follow (after I finish
writing them ;).
Change pickling format for bools to use a backwards compatible
encoding. This means you can pickle True or False on Python 2.3
and Python 2.2 or before will read it back as 1 or 0. The code
used for pickling bools before would create pickles that could
not be read in previous Python versions.
PEP 285. Everything described in the PEP is here, and there is even
some documentation. I had to fix 12 unit tests; all but one of these
were printing Boolean outcomes that changed from 0/1 to False/True.
(The exception is test_unicode.py, which did a type(x) == type(y)
style comparison. I could've fixed that with a single line using
issubtype(x, type(y)), but instead chose to be explicit about those
places where a bool is expected.
Still to do: perhaps more documentation; change standard library
modules to return False/True from predicates.
457466: popenx() argument mangling hangs python
226766: popen('python -c"...."') tends to hang
Fixes argument quoting in w9xpopen.exe for Windows 9x. w9xpopen.exe
also never attempts to display a MessageBox when not executed
interactively.
Added test_popen() test. This test currently just executes
"python -c ..." as a child process, and checks that the expected
arguments were all recieved correctly by the child process. This
test succeeds for me on Win9x, win2k and Linux, and I hope it does
for other popen supported platforms too :)
This fixes the symptom, but PRINT_ITEM has no way to know what (if
anything) PyFile_WriteObject() writes unless the object being printed
is a string. When the object isn't a string, this fix retains the
guess that softspace should be set after PyFile_WriteObject().
We might want to say that it's the job of filelike-object write methods
to leave the file's softspace in the correct state. That would probably
be better -- but everyone relies on PRINT_ITEM to guess for them now.
One more time on this turkey, but duller instead of cleverer.
Curious: The docs say __getslice__ has been deprecated since 2.0, but
list.__getitem__ still doesn't work if you pass it a slice. This makes
it a lot clearer to emulate a list by *being* a list <wink>.
Bugfix candidate. Michael, just pile this patch on top of the others
that went by -- no need to try to pick these apart.
The proper fix is not quite what was submitted; it's really better to
take the class of the object passed rather than calling PyMethod_New
with NULL pointer args, because that can then cause other core dumps
later.
I also added a testcase for the fix to classmethods() in test_descr.py.
I've already applied this to the 2.2 branch.
