[ 984722 ] Py_BuildValue loses reference counts on error

I'm ever-so-slightly uneasy at the amount of work this can do with an
exception pending, but I don't think that this can result in anything
more serious than a strange error message.

__module__ is the string name of the module the function was defined
in, just like __module__ of classes.  In some cases, particularly for
C functions, the __module__ may be None.

Change PyCFunction_New() from a function to a macro, but keep an
unused copy of the function around so that we don't change the binary
API.

Change pickle's save_global() to use whichmodule() if __module__ is
None, but add the __module__ logic to whichmodule() since it might be
used outside of pickle.

sense now that extension types can support __init__ directly rather
than requiring function constructors.

Closes SF bug #523473.

descriptor, as used for the tp_methods slot of a type.  These new flag
bits are both optional, and mutually exclusive.  Most methods will not
use either.  These flags are used to create special method types which
exist in the same namespace as normal methods without having to use
tedious construction code to insert the new special method objects in
the type's tp_dict after PyType_Ready() has been called.

If METH_CLASS is specified, the method will represent a class method
like that returned by the classmethod() built-in.

If METH_STATIC is specified, the method will represent a static method
like that returned by the staticmethod() built-in.

These flags may not be used in the PyMethodDef table for modules since
these special method types are not meaningful in that case; a
ValueError will be raised if these flags are found in that context.

- 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.

the object being inserted was not being DECREFed.

This closes SF bug #444486.

Python warning which can be catched by means of the Python warning
framework.

It also adds two new APIs which hopefully make it easier for Python
to switch to buffer overflow safe [v]snprintf() APIs for error
reporting et al. The two new APIs are PyOS_snprintf() and
PyOS_vsnprintf() and work just like the standard ones in many
C libs. On platforms which have snprintf(), the native APIs are used,
on all other an emulation with snprintf() tries to do its best.

    a Py_complex C value.

Patch by Walter Dörwald.
This partially closes SF patch #407148.

Add definitions of INT_MAX and LONG_MAX to pyport.h.
Remove includes of limits.h and conditional definitions of INT_MAX
and LONG_MAX elsewhere.

This closes SourceForge patch #101659 and bug #115323.

Add three new convenience functions to the PyModule_*() family:
PyModule_AddObject(), PyModule_AddIntConstant(), PyModule_AddStringConstant().

This closes SourceForge patch #101233.

B format char.

This should match the situation in the 1.6b1 tree.

python-dev discussion.

This should catch future version incompatibilities on Windows.  Alas,
this doesn't help for 1.5 vs. 1.6; but it will help for 1.6 vs. 2.0.

declarations yet, those come later.

Py_BuildValue.

tests.

Here's a patch which changes modsupport to add 'u' and 'u#',
to support building Unicode objects from a null-terminated
Py_UNICODE *, and a Py_UNICODE * with length, respectively.

[Conversion from 'U' to 'u' by Fred, based on python-dev comments.]

Note that the use of None for NULL values of the Py_UNICODE* value is
still in; I'm not sure of the conclusion on that issue.

Patch and suggestion by Greg Couch.

The MS compiler doesn't call it 'long long', it uses __int64,
so a new #define, LONG_LONG, has been added and all occurrences
of 'long long' are replaced with it.

which is now Py_BuildValue().

This is a bit of a hack: when the shared library is loaded, the module
name is "package.module", but the module calls Py_InitModule*() with just
"module" for the name.  The shared library loader squirrels away the true
name of the module in _Py_PackageContext, and Py_InitModule*() will
substitute this (if the name actually matches).

Py_Initmodule(), which is a macro wrapper around it).

The return value is now a NULL pointer if the initialization failed.
This may make old modules fail with a SEGFAULT, since they don't
expect this kind of failure.  That's OK, since (a) it "never" happens,
and (b) they would fail with a fatal error otherwise, anyway.

Tons of extension modules should now check the return value of
Py_Initmodule*() -- that's on my TODO list.