Otherwise, continue/break will attempt to affect the wrong loop.

A few more fiddles to get the SET_LINENOs consistent across compilers.

Always emit a SET_LINENO 0 at the beginning of the module.  The
builtin compiler does this, and it's much easier to compare bytecode
generated by the two compilers if they both do.

Move the SET_LINENO inside the FOR_LOOP block for list
comprehensions.  Also for compat. with builtin compiler.

CNRI copyright should be updated to include 2001.

Fix handling of unbound top-level methods.

basic authentication is needed.

Added documentation for FancyURLopener.prompt_user_passwd(), explaining
that subclasses should provide more appropriate behavior for the hosting
environment.

    Fix annoying bugs in flow graph layout code.  In some cases the
    implicit control transfers weren't honored.  In other cases,
    JUMP_FORWARD instructions jumped backwards.

    Remove unused arg from nextBlock().

pycodegen.py

    Add optional force kwarg to set_lineno() that will emit a
    SET_LINENO even if it is the same as the previous lineno.

    Use explicit LOAD_FAST and STORE_FAST to access list comp implicit
    variables.  (The symbol table doesn't know about them.)

Added documentation for TestCase.assertRaises().

Added text for "Mapping concepts to classes", and merged it into the
front matter instead of separating it into a new section.

Removed use of "assert" in examples.

Update the descriptions to reflect further changes from discussions on
the pyunit-interest list.

Added documentation for the defaultTestLoader object and the
TestLoader methods.

Added the assert*() names for the TestCase helper methods.

    "%#x" % 0
blew up, at heart because C sprintf supplies a base marker if and only if
the value is not 0.  I then fixed that, by tolerating C's inconsistency
when it does %#x, and taking away that *Python* produced 0x0 when
formatting 0L (the "long" flavor of 0) under %#x itself.  But after talking
with Guido, we agreed it would be better to supply 0x for the short int
case too, despite that it's inconsistent with C, because C is inconsistent
with itself and with Python's hex(0) (plus, while "%#x" % 0 didn't work
before, "%#x" % 0L *did*, and returned "0x0").  Similarly for %#X conversion.

those used by compile.c.  (test_grammar now depends on the names)

These format somewhat better and include more semantic information in the
source.

    the import.c machinery has soundly defeated my every attempt.

Ping on the Doc-SIG mailing list.

Fix so that docother() doesn't blow up.
Eliminate man() function since doc() and man() did nearly the same thing.
Various other code cleanup and refactoring to reduce duplication.
Simplify and rewrite freshimport() so modules are always up to date,
    even within packages (where reload() doesn't work).
Add finalization callback to the server (so that if the server fails to
    start for some reason, the main thread isn't left hanging).

- TestCase.failureException defines the exception that indicates a test failure
- Docstrings for TestLoader class
- Added exc_info() hack back in

Fixes last bug found with test_scope.py.

XXX Still doesn't work right for classes
XXX Still doesn't do sufficient error checking

Updated reference material substantially based on discussions on the
pyunit-interest mailing list (not all changes are in the code in CVS
yet).

only documentation file that appears to be affected by the change!

HTML markup from the string used as the title in the TITLE attribute.

This fixes formatting in the "What's New in Python 2.1" document.

Add Unixware 7 port
Ready for RC1
Minor rewrites

http://sourceforge.net/tracker/index.php?func=detail&aid=415514&group_id=5470&atid=105470
For short ints, Python defers to the platform C library to figure out what
%#x should do.  The code asserted that the platform C returned a string
beginning with "0x".  However, that's not true when-- and only when --the
*value* being formatted is 0.  Changed the code to live with C's inconsistency
here.  In the meantime, the problem does not arise if you format a long 0 (0L)
instead.  However, that's because the code *we* wrote to do %#x conversions on
longs produces a leading "0x" regardless of value.  That's probably wrong too:
we should drop leading "0x", for consistency with C, when (& only when) formatting
0L.  So I changed the long formatting code to do that too.

platform.  If it returns pi on the unixware7 platform, they have a bug in
their libm atan2.

prefix to the message lines.

This closes SF bug #415522.

Also fix markup error in text following the example.