removing useless obfuscation.

was intended to verify that sub-sequences of lengths 1 and 3 raise
ValueError, but was actually testing string lengths).

        - Describe UnpackTuple()
        - Credit __unicode__ to MAL
Use \pep macro everywhere in body text.
   (Listening to "The Great Gate of Kiev" -- appropriately triumphal
    music for this check-in...)

There's still a lot to do, but it's better now.

    to be covered in an overview article like this.

and suggeest that new code that does not require compatibility with older
Python versions subclass dictionary, list, or str.

happy.  (This does not cover everything it complained about, though.)

and functions: we only need to call PyObject_ClearWeakRefs() if the weakref
list is non-NULL.  Since these objects are common but weakrefs are still
unusual, saving the call at deallocation time makes a lot of sense.

Minor cleanups & markup consistency fixes.

PyObject_CallMethodObArgs().

PyObject_CallFunctionObArgs() and PyObject_CallMethodObArgs() have the
advantage that no format strings need to be parsed.  The CallMethod
variant also avoids creating a new string object in order to retrieve
a method from an object as well.

consistent (lack of) vertical space between sections, and remove some of the
unnecessary cruft that was added in (finally we get to *remove* something
that got generated!).

away completely next release, unless someone complains.

Reported by Thomas Heller.

outer level, the iterator protocol is used for memory-efficiency (the
outer sequence may be very large if fully materialized); at the inner
level, PySequence_Fast() is used for time-efficiency (these should
always be sequences of length 2).

dictobject.c, new functions PyDict_{Merge,Update}FromSeq2.  These are
wholly analogous to PyDict_{Merge,Update}, but process a sequence-of-2-
sequences argument instead of a mapping object.  For now, I left these
functions file static, so no corresponding doc changes.  It's tempting
to change dict.update() to allow a sequence-of-2-seqs argument too.

Also changed the name of dictionary's keyword argument from "mapping"
to "x".  Got a better name?  "mapping_or_sequence_of_pairs" isn't
attractive, although more so than "mosop" <wink>.

abstract.h, abstract.tex:  Added new PySequence_Fast_GET_SIZE function,
much faster than going thru the all-purpose PySequence_Size.

libfuncs.tex:
- Document dictionary().
- Fiddle tuple() and list() to admit that their argument is optional.
- The long-winded repetitions of "a sequence, a container that supports
  iteration, or an iterator object" is getting to be a PITA.  Many
  months ago I suggested factoring this out into "iterable object",
  where the definition of that could include being explicit about
  generators too (as is, I'm not sure a reader outside of PythonLabs
  could guess that "an iterator object" includes a generator call).
- Please check my curly braces -- I'm going blind <0.9 wink>.

abstract.c, PySequence_Tuple():  When PyObject_GetIter() fails, leave
its error msg alone now (the msg it produces has improved since
PySequence_Tuple was generalized to accept iterable objects, and
PySequence_Tuple was also stomping on the msg in cases it shouldn't
have even before PyObject_GetIter grew a better msg).

priority.  Add tp_cache; add some comments to others.

second noted after a second's thought about what the next line should
do. :-(

error occurs, and doesn't return a count.  (This is my second patch
from SF patch #474307, with small change to the docstring for send().)

2.1.2 "bugfix" candidate.

presentation.  This is acceptable since it only occurs in the formatted
output and does not affect the document markup.

When describing a Boolean return value, use "true" and "false" instead of
"1" and "0".
Style-guide conformance:  no "iff" -- to obscure for many readers.  ;-(

the separating semi-colon shows up on a continuation line (legal, but
weird).

Bug reported and fixed by Matthew Cowles.  Test case and sample email
included.

non-standard but common types.  Including Martin's suggestion to add
rejected non-standard types from patch #438790.  Specifically,

guess_type(), guess_extension(): Both the functions and the methods
grow an optional "strict" flag, defaulting to true, which determines
whether to recognize non-standard, but commonly found types or not.

Also, I sorted, reformatted, and culled duplicates from the big
types_map dictionary.  Note that there are a few non-equivalent
duplicates (e.g. .cdf and .xls) for which the first will just get
thrown away.  I didn't remove those though.

Finally, use of the module as a script as grown the -l and -e options
to toggle strictness and to do guess_extension(), respectively.

Doc and unittest updates too.

to call the corresponding methods.  This is not a performance improvement
since the times are still swamped by disk I/O, but cleans up the code just
a little.

Replace some tortuous code that was trying to be clever but forgot to
DECREF the key and value, by more longwinded but obviously correct
code.

(Inspired by but not copying the fix from SF patch #475033.)