Ripped out the docs for the new DocTestFinder's namefilter argument,
and renamed it to _namefilter; this only existed to support isprivate.
Removed the new DocTestFinder's objfilter argument.  No point adding
more cruft to a broken filtering design.

That's the title of the report, but the hole was probably plugged since
Python 2.0.  See corresponding checkin to PC/getpathp.c:  a crucial
precondition for joinpath() was neither documented nor verified, and there
are so many callers with so many conditional paths that no "eyeball
analysis" is satisfactory.  Now Python dies with a fatal error if the
precondition isn't satisfied, instead of allowing a buffer overrun.

NOT TESTED!  The Windows version of the patch was, but not this one.  I
don't feel like waiting for someone to notice the patch I attached to the
bug report.  If it doesn't compile, sorry, but fix it <wink>.  If it
does compile, it's "obviously correct".

[ 777659 ] Uninitialized variable used in Tools/faqwiz/faqwiz.py

with help from jlgijsbers on #python-dev IRC.

hack: it would resize *interned* strings in-place!  This occurred because
their reference counts do not have their expected value -- stringobject.c
hacks them.  Mea culpa.

as discussed on IRC.  The equivalent tests for the new behavior are in
test_builtin.py.

PyObject* o -> PyObject *o to be consistent with the
rest of the file
- Correct markup for Py_True
- Remove duplicate description of PyBool_Check

[Bug #914375] Crude modulefinder docs, but the module's code is very hard to read and it's not clear which bits are public and which aren't.  The module's author should really be doing this (and using docstrings in the code, too)

This test is insanely slow, so it requires a resource.  On my machine,
it also appears to dump core.  I think the problem is a stack
overflow, but haven't been able to confirm.

Don't generate code for asserts in -O mode.

interning were not clear here -- a subclass could be mutable, for
example -- and had bugs.  Explicitly interning a subclass of string
via intern() will raise a TypeError.  Internal operations that attempt
to intern a string subclass will have no effect.

Added a few tests to test_builtin that includes the old buggy code and
verifies that calls like PyObject_SetAttr() don't fail.  Perhaps these
tests should have gone in test_string.

This was probably fixed in rev 1.32 of getpath.c, but there are so
many paths thru the code that invoke joinpath() it's not at all
obvious that it *is* fixed.  It doesn't help confidence that a crucial
precondition for calling joinpath() was neither documented nor verified.
It is now, and joinpath() will barf with a fatal error now rather than
overrun the buffer, if the precondition isn't met.

Note that this patch only changes the Windows flavor.  I attached another
patch to the bug report for the POSIX flavor (which I can't test
conveniently).

[ 991812 ] PyArg_ParseTuple can miss errors with warnings as exceptions

as suggested in the report.

This is definitely a 2.3 candidate (as are most of the checkins I've
made in the last month...)

The change to use the newer httplib interface admitted the possibility
that we'd get an HTTP/1.1 chunked response, but the code didn't handle
it correctly.  The raw socket object can't be pass to addinfourl(),
because it would read the undecoded response.  Instead, addinfourl()
must call HTTPResponse.read(), which will handle the decoding.

One extra wrinkle is that the HTTPReponse object can't be passed to
addinfourl() either, because it doesn't implement readline() or
readlines().  As a quick hack, use socket._fileobject(), which
implements those methods on top of a read buffer.  (suggested by mwh)

Finally, add some tests based on test_urllibnet.

Thanks to Andrew Sawyers for originally reporting the chunked problem.

[ 1000841 ] "make pdf" failure w/ 2.4 docs

in the suggested way, by uglifying a URL.

[ 1003863 ] adds an index entry for __all__ to the tutorial

Michael Chermside's thinking about patch #748126 (the chief upshot of
which thinking was "reject it!").

Specifically, time.strftime() no longer accepts a 0 in the yday position of a
time tuple, since that can crash some platform strftime() implementations.

parsedate_tz(): Change the return value to return 1 in the yday position.

Update tests in test_rfc822.py and test_email.py