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.

iteritems() instead of materializing a (possibly giant) list of the
items.

The code is much easier to follow now, and I bet it's faster too.

make the bin-vs-not-bin order consistent with what other routines try to
do (they almost all handle the bin case first).

some notion of low-level efficiency.  Undid that, but left one routine
alone:  save_inst() claims it has a reason for not using memoize().
I don't understand that comment, so added an XXX comment there.

belongs.  This is a much smaller change than it may appear:  the bulk
of the function merely got unindented by one level.