initializing GNU readline, setlocale(LC_CTYPE, "") is called, which
changes the <ctype.h> macros to use the "default" locale (which isn't
the *initial* locale -- the initial locale is the "C" locale in which
only ASCII characters are printable). When the default locale is e.g.
Latin-1, the repr() of string objects can include 8-bit characters
with the high bit set; I believe this is due to the recent
PRINT_MULTIBYTE_STRING changes to stringobject.c. This in turn screws
up test_pyexpat and test_rotor, which depend on the repr() of 8-bit
strings with high bit characters.
The solution (for now) is to force the LC_CTYPE locale to "C" after
importing rlcompleter. This is the locale required by the test suite
anyway.
ths "should be" skipped depends on os.path.supports_unicode_filenames,
not really on the platform. Fiddled the expected-skip constructor
appropriately.
list(xrange(sys.maxint / 4))
test. Changed 4 to 2.
The belief is that this test intended to trigger a bit of code in
listobject.c's NRESIZE macro that's looking for arithmetic overflow. As
written, it doesn't achieve that, though, and leaves it up to the platform
realloc() as to whether it wants to allocate 2 gigabytes. Some platforms
say "sure!", although they don't appear to mean it, and disaster ensues.
Changing 4 to 2 (just barely) manages to trigger the arithmetic overflow
test instead, leaving the platform realloc() out of it.
I'll backport this to the 2.2 branch next.
sys.getwindowsversion() on Windows (new enahanced Tim-proof <wink>
version), and fix test_pep277.py in a few minor ways.
Including doc and NEWS entries.
patch #617312, both on the trunk and the 22-maint branch.
Also added a test case, and ported the test_trace I wrote for HEAD
to 2.2.2 (with all those horrible extra 'line' events ;-).
A possibility to deadlock (on the hidden import lock) was created here
in 2.3, seemingly when tempfile.py started to call functions in
random.py. The cure is "the usual": don't spawn threads as a side
effect of importing, when the spawned threads themselves do imports
(directly or indirectly), and the code that spawned the threads is
waiting for the threads to finish (they can't finish, because they're
waiting for the import lock the spawner still holds). Worming around
this is why the "test_main" mechanism was introduced in regrest, so
it's a straightforward fix.
NOT a bugfix candidate; the problem was introduced in 2.3.
module used in the Zope TAL implementation. The bug was already fixed
in the Python standard library, but the regression test would be good
to keep around.
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...
Martin v. Löwis
Guido van Rossum
Tim Peters
Mark Hammond
Michael W. Hudson
Jason Tishler
Fred Drake
Neal Norwitz
Barry Warsaw
Jack Jansen
Walter Dörwald