nor sufficient to make Python 2.0 compatible with the GPL, we won't
bother with it now.

In other words, we're still where we were weeks ago -- CNRI believes
that its license is GPL-compatible, Stallman says it's not.  I'm
trying to arrange a meeting between their lawyers so they can work it
out.  Whether dual licensing is the solution is open at this point.
If it is the (only!) solution, we'll add that to the BeOpen license
for 2.0 final.

Added a few clarifying footnotes and cross-references.
Various minor tweaks.

of distribution files in ftp://ftp.python.org/pub/python/src/).

separator in the href, not os.sep.

Added a <title> tag to directory listings.

Bumped version to 0.5.

Fabulous Prize for being our first Windows ME tester!  Also our only,
and I think he should get another prize just for that."

waste an hour tracking down an illusion; repaired it; writing/reading non-
printable characters (except \t\r\n) into/outof text-mode files ain't
defined x-platform, and at least some Windows text editors do surprising
things in their presence.
Also added a by-hand "build humber" to the Windows build, in an approximation
of Python's inexplicable BUILD-number Unix scheme.  I'll try to remember to
increment it each time I make a Windows installer available.  It's starting
at 2, cuz I've put 2 installers out so far (both with BUILD #0).

enable it), but db.h was not found, the WITH_LIBDB macros was still being
defined, resulting in compilation errors.  Also added a short explain when
bsddb support wasn't enabled (because db.h wasn't found) when the user
explicitly used --with-libdb on the configure command line.

    (pointed out by /F)

and this breaks the AIX build with an INT_MAX redefinition error.
"config.h" is included in pgenheaders.h, so moving this down fixes the
problem.

The returned file is assigned to an instance variable;
otherwise the implied close hangs for a long time.

AGREEMENT VERSION 1.

trade name -> trade names.

Note: depending on community feedback, we may end up taking the dual
licensing clause out for 2.0b1, and put it back into 2.0final, if
there's no other solution for assuring GPL compatibility by then.

See my message to python-dev and license-py20.

strings.  closes PEP-223.

also added \U escape (eight hex digits).

This was a funny one!  The test very subtly relied on 1.5.2's
behavior of treating "\x%" as "\x%", i.e. ignoring that was an
\x escape that didn't make sense.  But /F implemented PEP 223,
which causes 2.0 to raise an exception on the bad escape.
Fixed by merely making the 3 such strings of this kind into
raw strings.

BeOpen.com added to the front.

(Even if maybe we won't print this long banner at startup, the string
must still be defined for sys.copyright.)

changes suggested by BobW.

for 8-bit strings.

None (as documented) from start/end/span.  closes bug #113254

Tismer's clone, and to list Hajime Saitou's real name.

Added a note that the file uses Latin-1 (as distributed).

-- improved the SRE test harness: don't use asserts, test a few more
   things (including more boundary conditions)

can cause it to get called by multiple threads simultaneously.

Ditto for PyInterpreterState_Delete.

Of the former, the docs say "The interpreter lock need not be held, but may
be held if it is necessary to serialize calls to this function".  This
kinda implies it both is and isn't thread-safe.

Of the latter, the docs merely say "The interpreter lock need not be
held.", and the clause about serializing is absent.

I expect it was *believed* these are both thread-safe, and the bit about
serializing via the global lock was meant as a permission rather than a
caution.

I also expect we've never seen a problem here because the Python core
(prior to the _PyPclose fix) only calls these functions once per run.
The Py_NewInterpreter subsystem exposed by the C API (but not used by
Python itself) also calls them, but that subsystem appears to be very
rarely used.

Whatever, they're both thread-safe now.

"sre_parse.py missing '7' in DIGITS"

This should match the situation in the 1.6b1 tree.