raise ValueError. Checked in the patch as far as it went, but also changed
all of ints, longs and floats to raise ZeroDivisionError instead when raising
0 to a negative number. This is what 754-inspired stds require, as the "true
result" is an infinity obtained from finite operands, i.e. it's a singularity.
Also changed float pow to not be so timid about using its square-and-multiply
algorithm. Note that what math.pow does is unrelated to what builtin pow
does, and will still vary by platform.
apparently not considered a terminal, and so isatty(3) returns false. So we
skip the test for ttyness of the master side and just check the slave side,
which should really be a terminal.
cStringIO does not get it right (reported as SF bug #115531).
Added test for ValueError when write() is called on a closed StringIO
object. Commented out because cStringIO does not get it right
(reported as SF bug #115530).
flag is true, is set to a StringIO object that silently collects all
debug messages. This is triggered by the Node._debug=1 statement at
the top of test_minidom.py. After the tests, we better delete that
StringIO object to avoid wasting memory. We also reset the _debug
flag. (Note that this is an undetectable memory leak, and the memory
doesn't get collected by the cycle-gc either, because it's all
reachable -- it's just useless.)
Note a curious extension to the std C rules: x, X and o formatting can never produce
a sign character in C, so the '+' and ' ' flags are meaningless for them. But
unbounded ints *can* produce a sign character under these conversions (no fixed-
width bitstring is wide enough to hold all negative values in 2's-comp form). So
these flags become meaningful in Python when formatting a Python long which is too
big to fit in a C long. This required shuffling around existing code, which hacked
x and X conversions to death when both the '#' and '0' flags were specified: the
hacks weren't strong enough to deal with the simultaneous possibility of the ' ' or
'+' flags too, since signs were always meaningless before for x and X conversions.
Isomorphic shuffling was required in unicodeobject.c.
Also added dozens of non-trivial new unbounded-int test cases to test_format.py.
which implements the automatic conversion from Unicode to a string
object using the default encoding.
The new API is then put to use to have eval() and exec accept
Unicode objects as code parameter. This closes bugs #110924
and #113890.
As side-effect, the traditional C APIs PyString_Size() and
PyString_AsString() will also accept Unicode objects as
parameters.
reverse() didn't work at all due to bad arg check.
Fixed that.
Added Brad Chapman to ACKS file, as the proud new owner of two
implicitly copyrighted lines of Python source code <wink>.
Repaired buffer_info's total lack of arg-checking.
Replaced memmove by memcpy in reverse() guts, as memmove is
often slower and the memory areas are guaranteed disjoint.
Replaced poke-and-hope unchecked decl of tmp buffer size by
assert-checked larger tmp buffer.
Got rid of inconsistent spaces before open paren in docstrings.
Added reverse() sanity tests to test_array.py.
Strings are unpickled by calling eval on the string's repr. This
change makes pickle work like cPickle; it checks if the pickled
string is safe to eval and raises ValueError if it is not.
test suite modifications:
Verify that pickle catches a variety of insecure string pickles
Make test_pickle and test_cpickle use exactly the same test suite
Add test for pickling recursive object
character according to RFC 2396. Add some text to quote doc string
that explains the quoting rules better.
This closes SF Bug #114427.
Add _fast_quote operation that uses a dictionary instead of a list
when the standard set of safe characters is used.
waste an hour tracking down an illusion; repaired it; writing/reading non-
printable characters (except \t\r\n) into/outof text-mode files ain't
defined x-platform, and at least some Windows text editors do surprising
things in their presence.
Also added a by-hand "build humber" to the Windows build, in an approximation
of Python's inexplicable BUILD-number Unix scheme. I'll try to remember to
increment it each time I make a Windows installer available. It's starting
at 2, cuz I've put 2 installers out so far (both with BUILD #0).
This was a funny one! The test very subtly relied on 1.5.2's
behavior of treating "\x%" as "\x%", i.e. ignoring that was an
\x escape that didn't make sense. But /F implemented PEP 223,
which causes 2.0 to raise an exception on the bad escape.
Fixed by merely making the 3 such strings of this kind into
raw strings.
newlines at the start or end. Fiddle test_popen2 and popen2._test() to
tolerate this. Also change all "assert"s in these tests to raise
explicit exceptions, so that python -O doesn't render them useless.
Also, in case of error, make the msg display the reprs of what we
wrote and what we read, so we can tell exactly why it's failing.
Python test suite. Specifically,
- import time instead of strop in test_b1
- test for ClassType of exceptions using isinstance instead of
equality in test_exceptions
- remove __builtins__ from dir() output in test_pkg
test_pkg output needs to be regenerated.
In test_poll1(), unregister file descriptors as they're closed,
and also close the read end of the pipe
In test_poll2(), make the code assume less about the combinations of flag
bits that will be returned
subtle breakage on Windows (the test is skipped here, but the TestSkipped
exception wasn't recognized as such, because of duplicate copies of
test_support got loaded; so the test looks like a failure under Windows
instead of a skip).
Repaired the import, but
THIS TEST *WILL* FAIL ON OTHER SYSTEMS NOW!
Again due to the duplicate copies of test_support, the checked-in
"expected output" file actually contains verbose-mode output. I can't
generate the *correct* non-verbose output on my system. So, somebody
please do that.
rfc822 (Addresslist) modules. Also a preliminary testcase for augmented
assignment, which should actually be merged with the test_class testcase I
added last week.
docs changes are needed (only reference to winreg I could find
was in libwinreg.tex, which is documenting _winreg, and merely
mentions that a higher-level winreg module *may* appear someday;
that's still true).