"%#x" % 0
blew up, at heart because C sprintf supplies a base marker if and only if
the value is not 0. I then fixed that, by tolerating C's inconsistency
when it does %#x, and taking away that *Python* produced 0x0 when
formatting 0L (the "long" flavor of 0) under %#x itself. But after talking
with Guido, we agreed it would be better to supply 0x for the short int
case too, despite that it's inconsistent with C, because C is inconsistent
with itself and with Python's hex(0) (plus, while "%#x" % 0 didn't work
before, "%#x" % 0L *did*, and returned "0x0"). Similarly for %#X conversion.
http://sourceforge.net/tracker/index.php?func=detail&aid=415514&group_id=5470&atid=105470
For short ints, Python defers to the platform C library to figure out what
%#x should do. The code asserted that the platform C returned a string
beginning with "0x". However, that's not true when-- and only when --the
*value* being formatted is 0. Changed the code to live with C's inconsistency
here. In the meantime, the problem does not arise if you format a long 0 (0L)
instead. However, that's because the code *we* wrote to do %#x conversions on
longs produces a leading "0x" regardless of value. That's probably wrong too:
we should drop leading "0x", for consistency with C, when (& only when) formatting
0L. So I changed the long formatting code to do that too.
catch IOError as well as OverflowError. I found that on Tru64 Unix
this was raised; probably because the OS (or libc) doesn't support
large files but the architecture is 64 bits!
bugs on sizeof(long)==8 machines. pickle.py has no idea what it's
doing with very large ints, and variously gets things right by accident,
computes nonsense, or generates corrupt pickles. cPickle fails on
cases 2**31 <= i < 2**32: since it *thinks* those are 4-byte ints
(the "high 4 bytes" are all zeroes), it stores them in the (signed!) BININT
format, so they get unpickled as negative values.
integers, but the std tests don't exercise most of them. Repair that.
CAUTION: I expect this to fail on boxes with sizeof(long)==8, in the
part of test_cpickle (but not test_pickle) trying to do a binary mode
(not text mode) load of the embedded BINDATA pickle string. Once that
hypothesized failure is confirmed, I'll fix cPickle.c.
This applies the patch Fred Drake created to fix it.
I'm checking it in since I had to apply the patch anyway in order
to test its behavior on Windows.
used by Jython. The tests in this module expect C locale, so be
explicit about setting that (for CPython). However, in Jython, there
is no C locale, so instead be explicit about setting the US locale.
Closes the patch.
#403666. Specifically,
In codestr, force `c' to be global. It's unclear what the semantics
should be for a code object compiled at module scope, but bound and
run in a function. In CPython, `c' is global (by accident?) while in
Jython, `c' is local. The intent of the test clearly is to make `c'
global, so let's be explicit about it.
Jython also does not have a __builtins__ name in the module's
namespace, so we use a more portable alternative (though I'm not sure
why the test requires "__builtins__" in the g namespace).
Finally, skip the new.code() test if the new module doesn't have a
`code' attribute. Jython will never have this.
This makes verbose-mode output easier to dig thru, and removes an accidental
dependence on the order of dict.items() (made visible by recent changes to
dictobject.c).
of another list comp. This caused crashes reported as SF bugs 409230
and 407800.
Note that the new tests are in a function so that the name lookup code
isn't affected by how many *other* list comprehensions are in the same
scope.
Tim Peters
Guido van Rossum
Jeremy Hylton
Fred Drake
Barry Warsaw
Ka-Ping Yee
Fredrik Lundh
Thomas Wouters
Steve Purcell