refactoring to get all the duplicates of this delicate code out of the
cPickle and struct modules.

types.  The special handling for these can now be removed from save_newobj().
Add some testing for this.

Also add support for setting the 'fast' flag on the Python Pickler class,
which suppresses use of the memo.

Check return value of PyLong_AsDouble(), it can return an error.

long but the double is too big to fit in a long.  Prevent that.  This
closes some recent bug or patch on SF, but SF is down now so I can't
say which.

Bugfix candidate.

that is outside the integer range no longer raises OverflowError, but
returns a long object instead.

This fixes SF bug http://www.python.org/sf/635115

have a nb_float slot.  This matches what PyInt_AsLong does.

comments everywhere that bugged me: /* Foo is inlined */ instead of
/* Inline Foo */.  Somehow the "is inlined" phrase always confused me
for half a second (thinking, "No it isn't" until I added the missing
"here").  The new phrase is hopefully unambiguous.

The staticforward define was needed to support certain broken C
compilers (notably SCO ODT 3.0, perhaps early AIX as well) botched the
static keyword when it was used with a forward declaration of a static
initialized structure.  Standard C allows the forward declaration with
static, and we've decided to stop catering to broken C compilers.  (In
fact, we expect that the compilers are all fixed eight years later.)

I'm leaving staticforward and statichere defined in object.h as
static.  This is only for backwards compatibility with C extensions
that might still use it.

XXX I haven't updated the documentation.

strings or numbers

Another year in the quest to out-guess random C behavior.

Added macros Py_ADJUST_ERANGE1(X) and Py_ADJUST_ERANGE2(X, Y).  The latter
is useful for functions with complex results.  Two corrections to errno-
after-libm-call are attempted:

1. If the platform set errno to ERANGE due to underflow, clear errno.
   Some unknown subset of libm versions and link options do this.  It's
   allowed by C89, but I never figured anyone would do it.

2. If the platform did not set errno but overflow occurred, force
   errno to ERANGE.  C89 required setting errno to ERANGE, but C99
   doesn't.  Some unknown subset of libm versions and link options do
   it the C99 way now.

Bugfix candidate, but hold off until some Linux people actually try it,
with and without -lieee.  I'll send a help plea to Python-Dev.

delivered bizarre results.  Check float_divmod for a Py_NotImplemented
return and pass it along (instead of treating Py_NotImplemented as a
2-tuple).
CONVERT_TO_DOUBLE:  Added comments; this macro is obscure.

division functions, and rename to float_floor_div.

pass the buffer length.  Stop using it.  It should be deprecated, but too
late in the release cycle to do that now.
New static format_float() does the same thing but requires passing the
buffer length too.  Use it instead.

buffer overrun avoidance.

from optimizing away mod's sign adjustment when mod == 0; so it got
the intended result only in the debug build.

Try to ensure that divmod(-0.0, 1.0) -> (-0.0, +0.0) across platforms.
It always did on Windows, and still does.  It didn't on Linux.  Alas,
there's no platform-independent way to write a test case for this.
Bugfix candidate.

presence of NaNs.  So pass the issue on to the platform libm fabs();
after all, fabs() is a std C function because you can't implement it
correctly in portable C89.

Partial fix.
float_abs():  ensure abs(-0.0) returns +0.0.
Bugfix candidate.

many types were subclassable but had a xxx_dealloc function that
called PyObject_DEL(self) directly instead of deferring to
self->ob_type->tp_free(self).  It is permissible to set tp_free in the
type object directly to _PyObject_Del, for non-GC types, or to
_PyObject_GC_Del, for GC types.  Still, PyObject_DEL was a tad faster,
so I'm fearing that our pystone rating is going down again.  I'm not
sure if doing something like

void xxx_dealloc(PyObject *self)
{
	if (PyXxxCheckExact(self))
		PyObject_DEL(self);
	else
		self->ob_type->tp_free(self);
}

is any faster than always calling the else branch, so I haven't
attempted that -- however those types whose own dealloc is fancier
(int, float, unicode) do use this pattern.

float (compare the recent checkin to complex).  Added tests for these.

Inhibited complex unary plus optimization when applied to a complex subtype.
Added PyComplex_CheckExact macro.  Some comments and minor code fiddling.

optimization (+F(whatever)).

calls to PyXXX_CheckExact(X).

requires that errno ever get set, and it looks like glibc is already
playing that game.  New rules:

+ Never use HUGE_VAL.  Use the new Py_HUGE_VAL instead.

+ Never believe errno.  If overflow is the only thing you're interested in,
  use the new Py_OVERFLOWED(x) macro.  If you're interested in any libm
  errors, use the new Py_SET_ERANGE_IF_OVERFLOW(x) macro, which attempts
  to set errno the way C89 said it worked.

Unfortunately, none of these are reliable, but they work on Windows and I
*expect* under glibc too.

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.

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

PEP 238.  Changes:

- add a new flag variable Py_DivisionWarningFlag, declared in
  pydebug.h, defined in object.c, set in main.c, and used in
  {int,long,float,complex}object.c.  When this flag is set, the
  classic division operator issues a DeprecationWarning message.

- add a new API PyRun_SimpleStringFlags() to match
  PyRun_SimpleString().  The main() function calls this so that
  commands run with -c can also benefit from -Dnew.

- While I was at it, I changed the usage message in main() somewhat:
  alphabetized the options, split it in *four* parts to fit in under
  512 bytes (not that I still believe this is necessary -- doc strings
  elsewhere are much longer), and perhaps most visibly, don't display
  the full list of options on each command line error.  Instead, the
  full list is only displayed when -h is used, and otherwise a brief
  reminder of -h is displayed.  When -h is used, write to stdout so
  that you can do `python -h | more'.

Notes:

- I don't want to use the -W option to control whether the classic
  division warning is issued or not, because the machinery to decide
  whether to display the warning or not is very expensive (it involves
  calling into the warnings.py module).  You can use -Werror to turn
  the warnings into exceptions though.

- The -Dnew option doesn't select future division for all of the
  program -- only for the __main__ module.  I don't know if I'll ever
  change this -- it would require changes to the .pyc file magic
  number to do it right, and a more global notion of compiler flags.

- You can usefully combine -Dwarn and -Dnew: this gives the __main__
  module new division, and warns about classic division everywhere
  else.

This uses a slightly wimpy and wasteful approach, but it works. :-)

cases.
powu:  Deleted.

This started with a nonsensical error msg:

>>> x = -1.
>>> import sys
>>> x**(-sys.maxint-1L)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: negative number cannot be raised to a fractional power
>>>

The special-casing in float_pow was simply wrong in this case (there's
not even anything peculiar about these inputs), and I don't see any point
to it in *any* case:  a decent libm pow should have worst-case error under
1 ULP, so in particular should deliver the exact result whenever the exact
result is representable (else its error is at least 1 ULP).  Thus our
special fiddling for integral values "shouldn't" buy anything in accuracy,
and, to the contrary, repeated multiplication is less accurate than a
decent pow when the true result isn't exactly representable.  So just
letting pow() do its job here (we may not be able to trust libm x-platform
in exceptional cases, but these are normal cases).

- Do not compile unicodeobject, unicodectype, and unicodedata if Unicode is disabled
- check for Py_USING_UNICODE in all places that use Unicode functions
- disables unicode literals, and the builtin functions
- add the types.StringTypes list
- remove Unicode literals from most tests.

This introduces:

- A new operator // that means floor division (the kind of division
  where 1/2 is 0).

- The "future division" statement ("from __future__ import division)
  which changes the meaning of the / operator to implement "true
  division" (where 1/2 is 0.5).

- New overloadable operators __truediv__ and __floordiv__.

- New slots in the PyNumberMethods struct for true and floor division,
  new abstract APIs for them, new opcodes, and so on.

I emphasize that without the future division statement, the semantics
of / will remain unchanged until Python 3.0.

Not yet implemented are warnings (default off) when / is used with int
or long arguments.

This has been on display since 7/31 as SF patch #443474.

Flames to /dev/null.

It's guaranteed now, assuming the platform modf() works correctly.