return.  Setting an exception can mess with the exception state, and
continuing is definitely wrong (since type is dereferenced later on).
Some code that calls this seems to be prepared for a NULL exception
type, so let's be safe rather than sorry and simply assume there's
nothing to normalize in this case.

(contributed by Brett Cannon)

Bugfix candidate.

Bug fix candidate.

The cygwinccompiler.get_versions() function only handles versions numbers of
the form "x.y.z".  The attached patch enhances get_versions() to handle "x.y"
too (i.e., the ".z" is optional).

This change causes the unnecessary "--entry _DllMain@12" link option to be
suppressed for recent Cygwin and Mingw toolchains. Additionally, it directs
recent Mingw toolchains to use gcc instead of dllwrap during linking.

  MessageBeep().

Removed dead code.

- CHECK_VALID() was checking the wrong value for a closed fd
- fseek(&_iob[fileno], ...) doesn't work for fileno >= 20

exceptionally large totals etc.

  recursively.
- pdb has a new command, "debug", which lets you step through
  arbitrary code from the debugger's (pdb) prompt.

of saying x->ob_type.

typecheck that guarantees it's a string, and BTW string subclasses
could hide references.

Currently, the cygwinccompiler.py compiler handling in
distutils is invoking the cygwin and mingw compilers
with the -static option.

Logically, this means that the linker should choose to
link to static libraries instead of shared/dynamically
linked libraries.

Current win32 binutils expect import libraries to have
a .dll.a suffix and static libraries to have .a suffix.
If -static is passed, it will skip the .dll.a
libraries. This is pain if one has a tree with both
static and dynamic libraries using this naming
convention, and wish to use the dynamic libraries.

The -static option being passed in distutils is to get
around a bug in old versions of binutils where it would
get confused when it found the DLLs themselves.

The decision to use static or shared libraries is site
or package specific, and should be left to the setup
script or to command line options.

If a class was defined inside a function, used a static or class
method, and used super() inside the method body, it would be caught in
an uncollectable cycle.  (Simplified version: The static/class method
object would point to a function object with a closure that referred
to the class.)

Bugfix candidate.

when DST began.

These never failed in 2.3, and the tests confirm it.  They still blow up
in the 2.2 branch, despite that all the gc-vs-__del__ fixes from 2.3
have been backported (and this is expected -- 2.2 needs more work than
2.3 needed).

Based on a suggestion from a reader.