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.

then the embedded argument consumes at least 256 bytes.  The difference
between a 3-byte prefix (LONG2 + 2 bytes) and a 5-byte prefix (LONG4 +
4 bytes) is at worst less than 1%.  Note that binary strings and binary
Unicode strings also have only "size is 1 byte, or size is 4 bytes?"
flavors, and I expect for the same reason.  The only place a 2-byte
thingie was used was in BININT2, where the 2 bytes make up the *entire*
embedded argument (and now EXT2 also does this); that's a large savings
over 4 bytes, because the total opcode+argument size is so small in
the BININT2/EXT2 case.

Removed the TAKEN_FROM_ARGUMENT "number of bytes" code, and bifurcated it
into TAKEN_FROM_ARGUMENT1 and TAKEN_FROM_ARGUMENT4.  Now there's enough
info in ArgumentDescriptor objects to deduce the # of bytes consumed by
each opcode.

Rearranged the order in which proto2 opcodes are listed in pickle.py.