macostools.

isn't checked in yet. :-(

start for the C implemention of new pickle LONG1 and LONG4 opcodes (the
linear-time way to pickle a long is to call _PyLong_AsByteArray, but
the caller has no idea how big an array to allocate, and correct
calculation is a bit subtle).

possibility of calling save_reduce().  Add a special hack for this.
The tests for this are much simpler now (no __getstate__ or
__getnewargs__ needed).

Check return value of PyLong_AsDouble(), it can return an error.

after checking for __reduce__.

fixed a bug in load_newobj().

so merge from the bsddb-bsddb3-schizo-branch back to the trunk.

was used before string-escape codecs were added to the core.)

checks to save_reduce(), which can also be called from a subclass.)

Also tweaked some more comments.

they're easier to read this way.

of the opcode character instead (but stripping the quotes).

Added a proto 2 test section for the canonical recursive-tuple case.
Note that since pickle's save_tuple() takes different paths depending on
tuple length now, beefier tests are really needed (but not in pickletools);
the "short tuple" case tried here was actually broken yesterday, and it's
subtle stuff so needs to be tested.

be one of 0, 1 or 2).

I should note that the previous checkin also added NEWOBJ support to
the unpickler -- but there's nothing yet that generates this.

type 'object'.  Also minor docstring tweakage, and rearranged a few
lines in save().

memoized in text mode.  Fixed some variable names in the disassembler
doctest.

Martin's integration changes).

control flow had to be simplified.

incorrect for recursive tuples.  Tried to repair; seems to work OK, but
there are no checked-in tests for this yet.

Also moved the proto2 opcode descriptors into the sections they fit (like
TUPLE{1,2,3} in the group of tuple-building opcodes; etc).

NEWFALSE and NEWTRUE.

would be that the tuple is reversed on unpickling, and we should catch
that. :-)

Goodnight -- that's it for toniht!

Also moved the special case for empty tuples from save() to save_tuple().

change in meaning.

of my recent XXX comment, taking a (what appears to be vanishingly small)
chance and calling self.memoize() instead.

marshal.loads() beats struct.unpack()!  Possibly because the latter
creates a one-tuple. :-(

40% faster than marshal.dumps(x)[1:]!  (That's not counting the
module attribute lookups, which can be avoided in either case.)

created by recursive tuples.