See SF bug #551285.

handlers were both set, but were not compatible.  This change uses only the
tp_getattro handler with a more "modern" approach.
This fixes SF bug #551285.

Point to PEP 100 for MAL's Unicode proposal
Fix URL for XML HOWTO
Bump version number

strings or numbers

and xrange objects.
This closes SF bug #550555.

to make avoid regression.

This still does not work well since ctags does not do a good job with the
Python headers, appearantly due to the DL_IMPORT macro.  ;-(

This closes SF bug #550409.  Applying to release21-maint & release22-maint.

define info-lookup-maybe-add-help.

removed it from there and added it here)

selections (eg "-u network") being ignored.

(reported by François Pinard).
Added some missing "_" characters in the same cluster of productions.
Added missing floor division operator in m_expr production, and mention
floor division in the relevant portion of the text.

and allocate it in one gulp.

This isn't a bugfix, it's just a minor optimization that may or may not
pay off.

Bugfix candidate? Don't know how this is handled in the docs.

Unicode objects are currently taken as binary data by the write()
method.  This is not what Unicode users expect, nor what the
StringIO.py code does.  Until somebody adds a way to specify binary or
text mode for cStringIO objects, change the format string to use "t#"
instead of "s#", so that it will request the "text buffer" version.
This will try the default encoding for Unicode objects.

This is *not* a 2.2 bugfix (since it *is* a semantic change).

This now does a dynamic analysis of which elements are so frequently
repeated as to constitute noise.  The primary benefit is an enormous
speedup in find_longest_match, as the innermost loop can have factors
of 100s less potential matches to worry about, in cases where the
sequences have many duplicate elements.  In effect, this zooms in on
sequences of non-ubiquitous elements now.

While I like what I've seen of the effects so far, I still consider
this experimental.  Please give it a try!

memory management.

display a msg warning that the count of bytes requested may be bogus,
and that a segfault may happen next.

As threatened, PyMem_{Free, FREE} also invoke the object deallocator now
when pymalloc is enabled (well, it does when pymalloc isn't enabled too,
but in that case "the object deallocator" is plain free()).

This is maximally backward-compatible, but it leaves a bitter aftertaste.

Also massive reworking of comments.

_PyObject_GC_NewVar:  Could call PyObject_INIT_VAR likewise.

Bugfix candidate.

don't understand how this function works, also beefed up the docs.  The
most common usage error is of this form (often spread out across gotos):

	if (_PyString_Resize(&s, n) < 0) {
		Py_DECREF(s);
		s = NULL;
		goto outtahere;
	}

The error is that if _PyString_Resize runs out of memory, it automatically
decrefs the input string object s (which also deallocates it, since its
refcount must be 1 upon entry), and sets s to NULL.  So if the "if"
branch ever triggers, it's an error to call Py_DECREF(s):  s is already
NULL!  A correct way to write the above is the simpler (and intended)

	if (_PyString_Resize(&s, n) < 0)
		goto outtahere;

Bugfix candidate.

This implements ideas from Marc-Andre, Martin, Guido and me on Python-Dev.

"Short" Unicode strings are encoded into a "big enough" stack buffer,
then exactly as much string space as they turn out to need is allocated
at the end.  This should have speed benefits akin to Martin's "measure
once, allocate once" strategy, but without needing a distinct measuring
pass.

"Long" Unicode strings allocate as much heap space as they could possibly
need (4 x # Unicode chars), and do a realloc at the end to return the
untouched excess.  Since the overallocation is likely to be substantial,
this shouldn't burden the platform realloc with unusably small excess
blocks.

Also simplified uses of the PyString_xyz functions.  Also added a release-
build check that 4*size doesn't overflow a C int.  Sooner or later, that's
going to happen.

getpgrp(), and setpgid().
This closes SF bug #547939.

This closes SF bug #547953.

This closes SF patch #547162.