Because ob_size is a 32-bit int but sys.maxint is LONG_MAX which is a
64-bit value, there's no way to make this test succeed on a 64-bit
platform. So just skip it when sys.maxint isn't 0x7fffffff.
Backport candidate.
exception occurred so it should only be closed in the else clause.
Without this change we can an UnboundLocalError on Linux:
Traceback (most recent call last):
File "Lib/test/test_mmap.py", line 304, in ?
test_both()
File "Lib/test/test_mmap.py", line 208, in test_both
m.close()
UnboundLocalError: local variable 'm' referenced before assignment
with a size larger than the underlying file worked on Windows. It
does <wink>. However, merely creating an mmap that way has the side
effect of growing the file on disk to match the specified size. A
*later* test assumed that the file on disk was still exactly as it was
before the new "size too big" test was added, but that's no longer true.
So added a hack at the end of the "size too big" test to truncate the
disk file back to its original size on Windows.
Unicode strings (with arbitrary length) are allowed
as entries in the unicode.translate mapping.
Add a test case for multicharacter replacements.
(Multicharacter replacements were enabled by the
PEP 293 patch)
to fix it. (It fails when the day of the month is a 1-digit number,
because %c produces space+digit there, while strptime seems to expect
zero+digit somehow.)
of PyString_DecodeEscape(). This prevents a call to
_PyString_Resize() for the empty string, which would
result in a PyErr_BadInternalCall(), because the
empty string has more than one reference.
This closes SF bug http://www.python.org/sf/603937
Use a slightly different strategy to determine when not to call the line
trace function. This removes the need for the RETURN_NONE opcode, so
that's gone again. Update docs and comments to match.
Thanks to Neal and Armin!
Also add a test suite. This should have come with the original patch...
localtime, which in -0400 is 12 noon GMT. The bug boiled down to
broken conversion of 12 PM to hour 12 for the '%I %p' format string.
Added a test for this specific condition: Strptime12AMPMTests. Fix to
_strptime.py coming momentarily.
the tokenize module by test_tokenize.py. The FutureWarnings only
appeared during installation, and I've figured out a way to suppress
those in a different way.
sure these are the best fixes.
- Test maxint-1 against the negative octal constant -020000000000
- Comment out the tests for oct -1 and hex -1, since 037777777777 and
0xffffffff raise FutureWarnings now and in Python 2.4 those
constants will produce positive values, not negative values. So the
existing test seems to test something that won't be true in 2.4.
underlying dictionaries, there were no reasonable use cases (lexicographic
sorting of a list of sets is somewhat esoteric). Frees the operators
for other uses (such as strict subset and superset comparisons).
Updated documentation and test suite accordingly.
the inplace operators. The strategy is to have the operator overloading
code do the work and then to define equivalent method calls which rely on
the operators. The changes facilitate proper application of TypeError
and NonImplementedErrors.
Added corresponding tests to the test suite to make sure both the operator
and method call versions get exercised.
Add missing tests for difference_update().
wrong thing for a unicode subclass when there were zero string
replacements. The example given in the SF bug report was only one way
to trigger this; replacing a string of length >= 2 that's not found is
another. The code would actually write outside allocated memory if
replacement string was longer than the search string.
(I wonder how many more of these are lurking? The unicode code base
is full of wonders.)
Bugfix candidate; this same bug is present in 2.2.1.
base class (WrapperTestCase) instead, and call it repeatedly in the
methods that used to have a loop-over-subcases. Much simpler.
Rename perennial temp variable 't' to 'text'.
<peter@engcorp.com> based on a test script that's been kicking around my
home directory for a couple of months now and only saw the light of day
because I included it when I sent textwrap.py to python-dev for review.
Also, don't call gettempdir() in the default expression for the 'dir'
argument to various functions; use 'dir=None' for the default and
insert 'if dir is None: dir = gettemptir()' in the bodies. That way
the work done by gettempdir is postponed until needed.
[ 587993 ] SET_LINENO killer
Remove SET_LINENO. Tracing is now supported by inspecting co_lnotab.
Many sundry changes to document and adapt to this change.
binary=True
to
text=False
by BDFL Pronouncement. All other changes follow from this. The change
to the docs is ready to go, but blocked by another JackMacLock in the
doc directory.
do bizarre things to get a temp file, I changed it to use mkstemp instead
of NamedTemporaryFile. This tried to leave the file open while passing
its name to execfile(). On Win2K (but not Win9X), though, a file created
with O_TEMPORARY cannot be opened again, so the test failed with a
permission error when execfile tried to open it. Closer to the truth:
a file created with O_TEMPORARY can be opened again, but only if the
file is also created with SHARE_DELETE access via the Win32 CreateFile()
function. There's no way to get at that from MS's version of libc, though
(we'd have to ditch the "std" C file functions in favor of Win32 API
calls).
Close the bug report again -- this time for Cygwin due to a newlib bug.
See the following for the details:
http://sources.redhat.com/ml/newlib/2002/msg00369.html
Note that this commit is only a documentation (i.e., comment) change.
test was written. So boosted the number of "digits" this generates, and
also beefed up the "* / divmod" test to tickle numbers big enough to
trigger the Karatsuba algorithm. It takes about 2 seconds now on my box.
rewrite, by Zack Weinberg). This replaces most code in tempfile.py
(please review!!!) and adds extensive unit tests for it.
This will cause some warnings in the test suite; I'll check those in
soon, and also the docs.
least on OS/2 (see note on SF patch 555085 by A I MacIntyre) but
looks like the test *could* fail on any other platform too -- there's
no guarantee that recv() reads all data.
prints function and module names, which is more informative now that
we repeat some tests in slightly modified subclasses.
Add a test for read() until EOF.
Add test suites for line-buffered (bufsize==1) and a small custom
buffer size (bufsize==2).
Restructure testUnbufferedRead() somewhat to avoid a potentially
infinite loop.
and this broke a Zope "pipelining" test which read multiple responses
from the same connection (this attaches a new file object to the
socket for each response). Added a test for this too.
(I want to do some code cleanup too, but I thought I'd first fix
the problem with as little code as possible, and add a unit test
for this case. So that's what this checkin is about.)
on Windows. The test_sequence() ERROR is easily repaired if we're
willing to add an os.unlink() line to mhlib's updateline(). The
test_listfolders FAIL I gave up on -- I don't remember enough about Unix
link esoterica to recall why a link count of 2 is something a well-
written program should be keenly interested in <wink>.
Added new heapify() function, which transforms an arbitrary list into a
heap in linear time; that's a fundamental tool for using heaps in real
life <wink>.
Added heapyify() test. Added a "less naive" N-best algorithm to the test
suite, and noted that this could actually go much faster (building on
heapify()) if we had max-heaps instead of min-heaps (the iterative method
is appropriate when all the data isn't known in advance, but when it is
known in advance the tradeoffs get murkier).
at random, and replaces the elements at those positions with new random
values. I was pleasantly surprised by how fast this goes! It's hard to
conceive of an algorithm that could special-case for this effectively.
Plus it's exactly what happens if a burst of gamma rays corrupts your
sorted database on disk <wink>.
i 2**i *sort ... %sort
15 32768 0.18 ... 0.03
16 65536 0.24 ... 0.04
17 131072 0.53 ... 0.08
18 262144 1.17 ... 0.16
19 524288 2.56 ... 0.35
20 1048576 5.54 ... 0.77
and age of rampant computer breakins I imagine there are plenty of systems
with telnet disabled. Successful check of at least one getservbyname() call
is required for success
in the stability tests.
Bizarre: this takes 11x longer to run if and only if test_longexp is
run before it, on my box. The bigger REPS is in test_longexp, the
slower this gets. What happens on your box? It's not gc on my box
(which is good, because gc isn't a plausible candidate here).
The slowdown is massive in the parts of test_sort that implicitly
invoke a new-style class's __lt__ or __cmp__ methods. If I boost
REPS large enough in test_longexp, even the test_sort tests on an array
of size 64 visibly c-r-a-w-l. The relative slowdown is even worse in
a debug build. And if I reduce REPS in test_longexp, the slowdown in
test_sort goes away.
test_longexp does do horrid things to Win98's management of user
address space, but I thought I had made that a whole lot better a month
or so ago (by overallocating aggressively in the parser).
If the long is large enough, the return value will be a negative int.
In this case, calling the function a second time won't return the
original value passed in.
imports of test modules now import from the test package. Other
related oddities are also fixed (like DeprecationWarning filters that
weren't specifying the full import part, etc.). Also did a general
code cleanup to remove all "from test.test_support import *"'s. Other
from...import *'s weren't changed.
See there for a description.
Added test case.
Bugfix candidate for 2.2.x, not sure about previous versions:
probably low priority, because virtually no one runs debug builds.
imports e.g. test_support must do so using an absolute package name
such as "import test.test_support" or "from test import test_support".
This also updates the README in Lib/test, and gets rid of the
duplicate data dirctory in Lib/test/data (replaced by
Lib/email/test/data).
Now Tim and Jack can have at it. :)
array. Our samplesort special-cases the snot out of this, running about
12x faster than *sort. The experimental mergesort runs it about 8x
faster than *sort without special-casing, but should really do better
than that (when merging runs of different lengths, right now it only
does something clever about finding where the second run begins in
the first and where the first run ends in the second, and that's more
of a temp-memory optimization).
(i.e. email.test), so move the guts of them here from Lib/test. The
latter directory will retain stubs to run the email.test tests using
Python's standard regression test.
test_email_torture.py is a torture tester which will not run under
Python's test suite because I don't want to commit megs of data to
that project (it will fail cleanly there). When run under the mimelib
project it'll stress test the package with megs of message samples
collected from various locations in the wild.
version of PySlice_GetIndicesEx"):
> OK. Michael, if you want to check in indices(), go ahead.
Then I did what was needed, but didn't check it in. Here it is.
the default range to end at 2**20 (machines are much faster now).
Fixed what was quite a arguably a bug, explaining an old mystery: the
"!sort" case here contructs what *was* a quadratic-time disaster for
the old quicksort implementation. But under the current samplesort, it
always ran much faster than *sort (the random case). This never made
sense. Turns out it was because !sort was sorting an integer array,
while all the other cases sort floats; and comparing ints goes much
quicker than comparing floats in Python. After changing !sort to chew
on floats instead, it's now slower than the random sort case, which
makes more sense (but is just a few percent slower; samplesort is
massively less sensitive to "bad patterns" than quicksort).
existed at the time atexit first got imported. That's a bug, and this
fixes it.
Also reworked test_atexit.py to test for this too, and to stop using
an "expected output" file, and to test what actually happens at exit
instead of just simulating what it thinks atexit will do at exit.
Bugfix candidate, but it's messy so I'll backport to 2.2 myself.
The test of httplib makes it difficult to maintain httplib. There are
two many idioms that pyclbr doesn't seem to understand, and I don't
understand how to update these tests to make them work.
Also remove commented out test of urllib2.
takes much longer to run in the context of the test suite than when run in
isolation. That's because it forces a large number of full collections,
which take time proportional to the total number of gc'ed objects in the
whole system.
But since the dangerous implementation trickery that caused this test to
fail in 2.0, 2.1 and 2.2 doesn't exist in 2.3 anymore (the trashcan
mechanism stopped doing evil things when the possibility for compiling
without cyclic gc was taken away), such an expensive test is no longer
justified. This checkin leaves the test intact, but fiddles the
constants to reduce the runtime by about a factor of 5.
debug-build failure when an instance of a new-style class is resurrected
by a __del__ method -- we simply never had any code that tried this.
This is already fixed in 2.3 CVS. In 2.2.1, it blows up via
Fatal Python error: GC object already in linked list
I'll fix it in 2.2.1 CVS next.
.splitlines() on them, since they may be Header instances.
test_multilingual(), test_header_ctor_default_args(): New tests of
make_header() and that Header can take all default arguments.
ndiff function, so just alias it to assertEqual in that case.
Various: make sure all openfile()/read()'s are wrapped in
try/finally's so the file gets closed.
A bunch of new tests checking the corner cases for multipart/digest
and message/rfc822.
If multiple header fields with the same name occur, they are combined
according to the rules in RFC 2616 sec 4.2:
Appending each subsequent field-value to the first, each separated by
a comma. The order in which header fields with the same field-name are
received is significant to the interpretation of the combined field
value.
Guido van Rossum
Michael W. Hudson
Barry Warsaw
Tim Peters
Martin v. Löwis
Neal Norwitz
Jack Jansen
Walter Dörwald
Raymond Hettinger
Greg Ward
Andrew MacIntyre
Skip Montanaro
Jason Tishler
Marc-André Lemburg
Fred Drake
Piers Lauder
Jeremy Hylton
Thomas Heller