Probably should be backported.

This fixes a problem that math.sqrt(-1) doesn't raise math.error.

* Py_BuildValue("(OOO)",a,b,c)  -->  PyTuple_Pack(3,a,b,c)
* Py_BuildValue("()",a)         -->  PyTuple_New(0)
* Py_BuildValue("O", a)         -->  Py_INCREF(a)

Obtain cleaner coding and a system wide
performance boost by using the fast, pre-parsed
PyArg_Unpack function instead of PyArg_ParseTuple
function which is driven by a format string.

for Py_Main().

Thanks to Kalle Svensson and Skip Montanaro for the patches.

feature request 426539.

instead.

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.

SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES.
Work aroudn a bug in the SCO UnixWare atan2() implementation.

minimizes roundoff error.

getting Infs, NaNs, or nonsense in 2.1 and before; in yesterday's CVS we
were getting OverflowError; but these functions always make good sense
for positive arguments, no matter how large).

Repaired the ldexp docstring (said the name of the func was "ldexp_doc").

Peter Schneider-Kamp.
Clarified some docstrings in the spirit of the patch; left out the
degrees() and radians() functions (see the patch comments on SF).

libm result is 0).  Cautiously add a few libm exception test cases:
1. That exp(-huge) returns 0 without exception.
2. That exp(+huge) triggers OverflowError.
3. That sqrt(-1) raises ValueError specifically (apparently under glibc linked
   with -lieee, it was raising OverflowError due to an accident of the way
   mathmodule.c's CHECK() macro happened to deal with Infs and NaNs under gcc).

FRED, please check my monkey-see-monkey-do Tex fiddling!

This should match the situation in the 1.6b1 tree.

Py_FatalError() from module initialization functions.  The importing
mechanism already checks for PyErr_Occurred() after module importation
and it Does The Right Thing.

Unfortunately, the following either were not compiled or tested by the
regression suite, due to issues with my development platform:

	almodule.c
	cdmodule.c
	mpzmodule.c
	puremodule.c
	timingmodule.c

(and yes, "Currintly" also counts <0.5 wink>)

marked my*.h as obsolete

and a couple of functions that were missed in the previous batches. Not
terribly tested, but very carefully scrutinized, three times.

All these were found by the little findkrc.py that I posted to python-dev,
which means there might be more lurking. Cases such as this:

long
func(a, b)
	long a;
	long b; /* flagword */
{

and other cases where the last ; in the argument list isn't followed by a
newline and an opening curly bracket. Regexps to catch all are welcome, of
course ;)

Revise math_1(), math_2(), stub-generating macros, and function tables to
use PyArg_ParseTuple() and properly provide the function name for error
message generation.
Fix pow() docstring for MPW 3.1; had said "power" instead of "pow".

Reported on c.l.py by Kirill Simonov.

that before) in the previous patch has one problem; rint() is not in
the C math library on all platforms (e.g. not for VC++).  Make it
conditional on HAVE_RINT.

Fix overflow bug in ldexp(x, exp). The 'exp' argument maps to a C int for the
math library call [double ldexp(double, int)], however the 'd'
PyArg_ParseTuple formatter was used to yield a double, which was subsequently
cast to an int. This could overflow.

[GvR: mysteriously, on Solaris 2.7, ldexp(1, 2147483647) returns Inf
while ldexp(1, 2147483646) raises OverflowError; this seems a bug in
the math library (it also takes a real long time to compute the
Inf outcome).  Does this point to a bug in the CHECK() macro?  It
should have discovered that the result was outside the HUGE_VAL range.]

on BeOS or Windows.