Briefly (from the NEWS file):

- Updates for the email package:
  + All deprecated APIs that in email 2.x issued warnings have been removed:
    _encoder argument to the MIMEText constructor, Message.add_payload(),
    Utils.dump_address_pair(), Utils.decode(), Utils.encode()
  + New deprecations: Generator.__call__(), Message.get_type(),
    Message.get_main_type(), Message.get_subtype(), the 'strict' argument to
    the Parser constructor.  These will be removed in email 3.1.
  + Support for Python earlier than 2.3 has been removed (see PEP 291).
  + All defect classes have been renamed to end in 'Defect'.
  + Some FeedParser fixes; also a MultipartInvariantViolationDefect will be
    added to messages that claim to be multipart but really aren't.
  + Updates to documentation.

deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".

deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.

deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before).  Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...

deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed.  Added a test.

I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c.  On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble.  (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())

ages. The main improvements are:
- a much more convenient API: readPlist() and writePlist()
- support non-dict top-level objects

  The previous approach was too easily fooled (a rotate() sufficed).

* Use it->counter to determine when iteration is complete.  The
  previous approach was too complex.

* Strengthen an assertion and add a comment here or there.

* Change the centering by one to make it possible to test the module
  with BLOCKLEN's as low as two.  Testing small blocks makes end-point
  errors surface more readily.

BLOCKLEN-1, this assert-failed in a debug build, or went wild with a
NULL pointer in a release build.  Reported on c.l.py by Stefan Behnel.

which isn't being converted from reST yet).

Many of these tests are redundant, but this will ensure
that the mapping protocols all stay in sync.
Also, added a test for dictionary subclasses.

* Updated docs to reflected signed return values.
* Fixed a doubled word typo.

Rather than introduce new logic, took the approach of making the message
itself more general.

(Suggested by Michael Hudson.)

repr(66.6) == "66.6", so doubt that the claimed output has ever been seen.
Changed it to 66.25 everywhere, and manually verified that the new claimed
output is correct.

request.  Tim says that "correct 'fuzzy' comparison of floats cannot
be automated."  (The motivation behind adding the new option
was verifying interactive examples in Python's latex documentation;
several such examples use numbers that don't print consistently on
different platforms.)

* Have groupby() be careful about decreffing structure members.

the expected output to match corresponding number literals in the
actual output if their values are equal (to ten digits of precision).

the proper path directories for compiling extension modules.