This closes SF patch #451538.

    have used the attribute argument provided as a parameter

mostly changes of / operators into //.  Once or twice I did more or
less than recommended.

way it's called each time a generator is resumed.  The tracing of normal
functions should be unaffected by this change.

This closes SF bug #458223.

Fixed a markup error which caused an em dash to be presented as a minus sign.
This closes SF bug #458350.

change their basic behavior:  When parsing something that cannot possibly
be valid in either HTML or XHTML, raise an exception.

  operators per line or statement are now on by default, and -m turns
  these warnings off.

- Change the way multiple / operators are reported; a regular
  recommendation is always emitted after the warning.

- Report ambiguous warnings (both int|long and float|complex used for
  the same operator).

- Update the doc string again to clarify all this and describe the
  possible messages more precisely.

the -Qwarnall option, so I've changed this to only filter out the one
warning that's a problem in practice.

broken declaration-like things.

regarding bare ampersands in content.

Fixed.

curses, far too old for _cursesmodule.c.

e.g., (1L << 40000)/(1L << 40001) returns 0.5, not Inf or NaN or whatever.

the fiddling is simply due to that no caller of PyLong_AsDouble ever
checked for failure (so that's fixing old bugs).  PyLong_AsDouble is much
faster for big inputs now too, but that's more of a happy consequence
than a design goal.

division, and this makes sense.  Add -Qwarnall to warn for all
classic divisions, as required by the fixdiv.py tool.

but will be the foundation for Good Things:
+ Speed PyLong_AsDouble.
+ Give PyLong_AsDouble the ability to detect overflow.
+ Make true division of long/long nearly as accurate as possible (no
  spurious infinities or NaNs).
+ Return non-insane results from math.log and math.log10 when passing a
  long that can't be approximated by a double better than HUGE_VAL.

of PyMapping_Keys because we know we have a real dict.  Tolerate that
objects may have an attr named "__dict__" that's not a dict (Py_None
popped up during testing).

test_descr.py, test_dir():  Test the new classic-class behavior; beef up
the new-style class test similarly.

test_pyclbr.py, checkModule():  dir(C) is no longer a synonym for
C.__dict__.keys() when C is a classic class (looks like the same thing
that burned distutils! -- should it be *made* a synoym again?  Then it
would be inconsistent with new-style class behavior.).

disabled.  Obviously everyone enables the GC. :-)

integer types, and y must be >= 0.  See discussion at
http://sf.net/tracker/index.php?func=detail&aid=457066&group_id=5470&atid=105470

bag.  It's clearly wrong for classic classes, at heart because a classic
class doesn't have a __class__ attribute, and I'm unclear on whether
that's feature or bug.  I'll repair this once I find out (in the
meantime, dir() applied to classic classes won't find the base classes,
while dir() applied to a classic-class instance *will* find the base
classes but not *their* base classes).

Please give the new dir() a try and see whether you love it or hate it.
The new dir([]) behavior is something I could come to love.  Here's
something to hate:

>>> class C:
...     pass
...
>>> c = C()
>>> dir(c)
['__doc__', '__module__']
>>>

The idea that an instance has a __doc__ attribute is jarring (of course
it's really c.__class__.__doc__ == C.__doc__; likewise for __module__).

OTOH, the code already has too many special cases, and dir(x) doesn't
have a compelling or clear purpose when x isn't a module.

Tested, too:-)

treated the same as single ones by default.  Added -m option to issue
a warning for this case instead.

mapping object", in the same sense dict.update(x) requires of x (that x
has a keys() method and a getitem).
Questionable:  The other type constructors accept a keyword argument, so I
did that here too (e.g., dictionary(mapping={1:2}) works).  But type_call
doesn't pass the keyword args to the tp_new slot (it passes NULL), it only
passes them to the tp_init slot, so getting at them required adding a
tp_init slot to dicts.  Looks like that makes the normal case (i.e., no
args at all) a little slower (the time it takes to call dict.tp_init and
have it figure out there's nothing to do).