| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
64-bit INTs on 32-bit boxes (where they become longs). Also exploit that
int(str) and long(str) will ignore a trailing newline (saves creating a
new string at the Python level).
pickletester.py: Simulate reading a pickle produced by a 64-bit box.
|
| |
|
|
|
|
|
|
| |
- Do not compile unicodeobject, unicodectype, and unicodedata if Unicode is disabled
- check for Py_USING_UNICODE in all places that use Unicode functions
- disables unicode literals, and the builtin functions
- add the types.StringTypes list
- remove Unicode literals from most tests.
|
| |
|
|
|
|
| |
than from module pickletester. Using the latter turned out to cause
the test to break when invoked as "import test.test_pickle" or "import
test.autotest".
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
the logic better. Will be adding some additional tests later today.
|
| | |
|
|
|
they're run.
|
