in more detail, and use them where appropriate.

parameters, given a hyperlink to the right part of the documentation to
make it easier to look those up.  Also, refer to the file() function/
constructor instead of open() now that that is where the actual docs for
those parameters live.
This closes SF bug #472004.

should have been checked in as part of patch #470254.

use the correct base for a buffer object in _PyBuffer_FromObject.

This appears to be a case of a missing \n\ in a multiline string
literal.

This patch should also be applied to the 2.2b1 trunk.

anything about the hotshot profiler, this file is ready for the 2.2b1
Windows build.

epilogue, based on the discussion in this SF bug report:

https://sourceforge.net/tracker/index.php?func=detail&aid=472481&group_id=25568&atid=384678

    TestMIMEMessage.test_epilogue(), TestIdempotent.test_preamble_epilogue():
    Test cases for SF bug #472481.

    _handle_multipart(): If there is an epilogue and the epilogue does
    not itself start with a newline, add a newline before writing the
    epilogue.  Closes SF bug #472481.

    This patch implements what we have discussed on python-dev late in
    September: str(obj) and unicode(obj) should behave similar, while
    the old behaviour is retained for unicode(obj, encoding, errors).

    The patch also adds a new feature with which objects can provide
    unicode(obj) with input data: the __unicode__ method. Currently no
    new tp_unicode slot is implemented; this is left as option for the
    future.

    Note that PyUnicode_FromEncodedObject() no longer accepts Unicode
    objects as input. The API name already suggests that Unicode
    objects do not belong in the list of acceptable objects and the
    functionality was only needed because
    PyUnicode_FromEncodedObject() was being used directly by
    unicode(). The latter was changed in the discussed way:

    * unicode(obj) calls PyObject_Unicode()
    * unicode(obj, encoding, errors) calls PyUnicode_FromEncodedObject()

    One thing left open to discussion is whether to leave the
    PyUnicode_FromObject() API as a thin API extension on top of
    PyUnicode_FromEncodedObject() or to turn it into a (macro) alias
    for PyObject_Unicode() and deprecate it. Doing so would have some
    surprising consequences though, e.g.  u"abc" + 123 would turn out
    as u"abc123"...

[Marc-Andre didn't have time to check this in before the deadline.  I
hope this is OK, Marc-Andre!  You can still make changes and commit
them on the trunk after the branch has been made, but then please mail
Barry a context diff if you want the change to be merged into the
2.2b1 release branch.  GvR]

    In Include/, marshal.h declares both
    PyMarshal_ReadLongFromFile()
    and PyMarshal_ReadShortFromFile(),
    but the second is missing from marshal.c.

[Shouldn't the return type be declared as 'short' instead of 'int'?
But 'int' is what was in marshal.h all those years...  --Guido]

This adds unsetenv to posix, and uses it in the __delitem__ method of
os.environ.

(XXX Should we change the preferred name for putenv to setenv, for
consistency?)

This was submitted by Moshe, but apparently he's too busy to check it
in himself.  He wrote:

    Here is a function in GNU readline called add_history,
    which is used to manage the history list. Though Python
    uses this function internally, it does not expose it to
    the Python programmer. This patch adds direct interface
    to this function with documentation.

    This could be used by friendly modules to "seed" the
    history with commands.

199712 didn't have dlfcn.h, or that it wouldn't conflict with the other
stuff defined.

TypeError (on systems where it's not defined at all, it raises
AttributeError; when it's defined, assignment to it raises TypeError).

Some AIX compiler didn't like the trailing comma at the end of the
why_code enum decl.

This is a big one, touching lots of files.  Some of the platforms
aren't tested yet.  Briefly, this changes the return value of the
os/posix functions stat(), fstat(), statvfs(), fstatvfs(), and the
time functions localtime(), gmtime(), and strptime() from tuples into
pseudo-sequences.  When accessed as a sequence, they behave exactly as
before.  But they also have attributes like st_mtime or tm_year.  The
stat return value, moreover, has a few platform-specific attributes
that are not available through the sequence interface (because
everybody expects the sequence to have a fixed length, these couldn't
be added there).  If your platform's struct stat doesn't define
st_blksize, st_blocks or st_rdev, they won't be accessible from Python
either.

(Still missing is a documentation update.)

The GUI-mode code to display properties blew up if the property functions
(get, set, etc) weren't simply methods (or functions).

"The problem" here is really that the generic document() method dispatches
to one of .doc{routine, class, module, other}(), but all of those require
a different(!) number of arguments.  Thus document isn't general-purpose
at all:  you have to know exactly what kind of thing is it you're going
to document first, in order to pass the correct number of arguments to
.document for it to pass on.  As an expedient hack, just tacked "*ignored"
on to the end of the formal argument lists for the .docXXX routines so
that .document's caller doesn't have to know in advance which path
.document is going to take.

<grp.h> it seems.  This requires yet another configure test.

#463572.  Closing.

The right fix is to generate line number events anyway ;-), but this will
have to do for now.

    compile should raise error for non-strings
SRE bug #432570, 448951:
    reset group after failed match

also bumped version number to 2.2.0