__call__() can be 2-3x slower than the equivalent normal method.

_handle_message(): The structure of message/rfc822 message has
changed.  Now parent's payload is a list of length 1, and the zeroth
element is the Message sub-object.  Adjust the printing of such
message trees to reflect this change.

There's some wierdness here, but the test ran before and not after,
so I'm just hacking the change out.  Someone more motivated than
me can work out what's really happening.

Raymond: *PLEASE* run the test suite before checking things like
this in!

compiler. Fixes #559429. 2.2 bugfix candidate.

subclasses.

MIMENonMultipart: Base class for non-multipart/* content type subclass
specializations, e.g. image/gif.  This class overrides attach() which
raises an exception, since it makes no sense to attach a subpart to
e.g. an image/gif message.

MIMEMultipart: Base class for multipart/* content type subclass
specializations, e.g. multipart/mixed.  Does little more than provide
a useful constructor.

better code reuse.

_split() Use _floordiv().

debug build.  Repaired that, and rewrote other parts to reduce
long-winded casting.

Python 2.1 compatibility.

If a rexec instance allows writing in the current directory (a common
thing to do), there's a way to execute bogus bytecode.  Fix this by
not allowing imports from .pyc files (in a way that allows a site to
configure things so that .pyc files *are* allowed, if writing is not
allowed).

I'll apply this to 2.2 and 2.1 too.

In the past, an object's tp_compare could return any value.  In 2.2
the docs were tightened to require it to return -1, 0 or 1; and -1 for
an error.

We now issue a warning if the value is not in this range.  When an
exception is raised, we allow -1 or -2 as return value, since -2 will
the recommended return value for errors in the future.  (Eventually
tp_compare will also be allowed to return +2, to indicate
NotImplemented; but that can only be implemented once we know all
extensions return a value in [-2...1].  Or perhaps it will require the
type to set a flag bit.)

I haven't decided yet whether to backport this to 2.2.x.  The patch
applies fine.  But is it fair to start warning in 2.2.2 about code
that worked flawlessly in 2.2.1?

mode).