Andrew quite correctly notices that the next() method isn't quite what
we need, since it returns None upon end instead of raising
StopIteration. His fix is easy enough, using iter(self.next, None)
instead.
with the same value instead. This ensures that a string (or string
subclass) object's ob_sinterned pointer is always a str (or NULL), and
that the dict of interned strings only has strs as keys.
+ These were leaving the hash fields at 0, which all string and unicode
routines believe is a legitimate hash code. As a result, hash() applied
to str and unicode subclass instances always returned 0, which in turn
confused dict operations, etc.
+ Changed local names "new"; no point to antagonizing C++ compilers.
subclasses, all "the usual" ones (slicing etc), plus replace, translate,
ljust, rjust, center and strip. I don't know how to be sure they've all
been caught.
Question: Should we complain if someone tries to intern an instance of
a string subclass? I hate to slow any code on those paths.
#460112 by Gerhard Haering.
(With slight layout changes to conform to docstrings guidelines and to
prevent a line longer than 78 characters. Also fixed some docstrings
that Gerhard didn't touch.)
tuple(i) repaired to return a true tuple when i is an instance of a
tuple subclass.
Added PyTuple_CheckExact macro.
PySequence_Tuple(): if a tuple-like object isn't exactly a tuple, it's
not safe to return the object as-is -- make a new tuple of it instead.
Given an immutable type M, and an instance I of a subclass of M, the
constructor call M(I) was just returning I as-is; but it should return a
new instance of M. This fixes it for M in {int, long}. Strings, floats
and tuples remain to be done.
Added new macros PyInt_CheckExact and PyLong_CheckExact, to more easily
distinguish between "is" and "is a" (i.e., only an int passes
PyInt_CheckExact, while any sublass of int passes PyInt_Check).
Added private API function _PyLong_Copy.
If on Windows, we require the 'largefile' resource.
If not on Windows, we use a test that actually writes a byte beyond
the 2BG limit -- seeking alone is not sufficient, since on some
systems (e.g. Linux with glibc 2.2) the sytem call interface supports
large seek offsets but not all filesystem implementations do.
Note that on Windows, we do not use the write test: on Win2K, that
test can take a minute trying to zero all those blocks on disk, and on
Windows our code always supports large seek offsets (but again, not
all filesystems do). This may mean that on Win95, or on certain other
backward filesystems, test_largefile will *fail*.
horridly inefficient hack in regrtest's Compare class, but it's about as
clean as can be: regrtest has to set up the Compare instance before
importing a test module, and by the time the module *is* imported it's too
late to change that decision. The good news is that the more tests we
convert to unittest and doctest, the less the inefficiency here matters.
Even now there are few tests with large expected-output files (the new
cost here is a Python-level call per .write() when there's an expected-
output file).
iterable object. I'm not sure how that got overlooked before!
Got rid of the internal _PySequence_IterContains, introduced a new
internal _PySequence_IterSearch, and rewrote all the iteration-based
"count of", "index of", and "is the object in it or not?" routines to
just call the new function. I suppose it's slower this way, but the
code duplication was getting depressing.
saving instead a traceback string, but test_support's run_unittest was
still peeking into unittest internals and trying to pick apart unittest's
errors and failures vectors as if they contained exc_info() tuples instead
of strings.
Whatever, when a unittest-based test failed, test_support blew up. I'm
not sure this is the right way to fix it; it simply gets me unstuck.
capabilities of the Pentium FPU, so what should have been (and were on
Windows) exact results got fuzzy. Then it turns out test_support.fcmp()
isn't tolerant of tiny errors when *one* of the comparands is 0, but
test_complex's old check_close_real() is. Rather than fix gcc <wink>,
easier to revert this test and revisit after the release.
(1) Allow multiple -u options to extend each other (and the initial
value of use_resources passed into regrtest.main()).
(2) When a test is run stand-alone (not via regrtest.py), needed
resources are always granted.
added all the telnet options known to arpa/telnet.h
added all the options registered with IANA as of today
added the possibility for the user to have it's own option negotiation callback
This patch is similar to that proposed by Jeremy. The proposed patch altered
the interface of TestResult such that it would be passed the error
information as a string rather than an exc_info() tuple.
The implemented change leaves the interface untouched so that TestResults
are still passed the tracebacks, but stor them in stringified form for
later reporting.
Notes:
- Custom subclasses of TestResult written by users should be unaffected.
- The existing 'unittestgui.py' will still work with this module after the
change.
- Support can later be added to pop into the debugger when an error occurs;
this support should be added to a TestRunner rather than to TestCase itself,
which this change will enable.
(Jeremy, Fred, Guido: Thanks for all the feedback)
1. That seeking beyond the end of a file increases the size of a file.
2. That files so extended are magically filled with null bytes.
I find no support for either in the C std, and #2 in particular turns out
not to be true on Win32 (you apparently see whatever trash happened to be
on disk). Left #1 intact, but changed the test to check only bytes it
explicitly wrote. Also fiddled the "expected" vs "got" failure reports
to consistently use repr (%r) -- they weren't readable otherwise.
Guido van Rossum
Tim Peters
Martin v. Löwis
Fredrik Lundh
Jeremy Hylton
Barry Warsaw
Fred Drake
Steve Purcell