PyTuple_GetItem() with PyTuple_GET_SIZE() and PyTuple_GET_ITEM().
    The code has already done a PyTuple_Check().

If we have a PyCFunction (builtin) and it is METH_VARARGS only, load
the args and dispatch to call_cfunction() directly.  This provides a
small speedup for perhaps the most common function calls -- builtins.

TAL/PageTemplate package for Zope.  This only needed a little boilerplate
change; the tests themselves are unchanged.

derived from but not quite compatible with that of sgmllib, so it's a
new file.  I suppose it needs documentation, and htmllib needs to be
changed to use this instead of sgmllib, and sgmllib needs to be
declared obsolete.  But that can all be done later.

This code was first published as part of TAL (part of Zope Page
Templates), but that was strongly based on sgmllib anyway.  Authors
are Fred drake and Guido van Rossum.

in the comments for using two passes was bogus, as the only object that
can get decref'ed due to the copy is the dummy key, and decref'ing dummy
can't have side effects (for one thing, dummy is immortal!  for another,
it's a string object, not a potentially dangerous user-defined object).

Dynamically loaded toolbox modules don't need to link against each other anymore, due to the new glue code that ties them together.

Glue code to connect obj_New and obj_Convert routines (the PyArg_Parse and Py_BuildTuple helpers) from one dynamically imported module to another.

First step in porting MacPython modules to OSX/unix: break all references between modules except for the obj_New() and obj_Convert() routines, the PyArg_Parse and Py_BuildValue helpers.

And these can now be vectored through glue routines (by defining USE_TOOLBOX_OBJECT_GLUE) which will do the necessary imports, whereupon the module's init routine will tell the glue routine about the real conversion routine address and everything is fine again.

but it still can't have any syntax errors.  Went a little too fast
there, Jack? :-)

Made distutils understand the MacPython Carbon runtime model. Distutils will build for the runtime model you are currently using for the interpreter.

exist in latin1, but at least the roundtrip results in the
same macroman characters.

Fixed macroman<->latin1 conversion. Some characters don't exist in latin1, but at least the roundtrip gives
the correct macroman characters again.

codec files to codecs.py and added logic so that multi mappings
in the decoding maps now result in mappings to None (undefined mapping)
in the encoding maps.

Bah, somehow the macroman<->iso-latin-1 translation got lost during the merge. Checking in one fixed file to make sure MacCVS Pro isn't the problem. If it isn't a flurry of checkins will follow tomorrow. If it is... well...

1. Omit the early-out EQ/NE "lengths different?" test.  Was unable to find
   any real code where it triggered, but it always costs.  The same is not
   true of list richcmps, where different-size lists appeared to get
   compared about half the time.
2. Because tuples are immutable, there's no need to refetch the lengths of
   both tuples from memory again on each loop trip.

BUG ALERT:  The tuple (and list) richcmp algorithm is arguably wrong,
because it won't believe there's any difference unless Py_EQ returns false
for some corresponding elements:

>>> class C:
...     def __lt__(x, y): return 1
...     __eq__ = __lt__
...
>>> C() < C()
1
>>> (C(),) < (C(),)
0
>>>

That doesn't make sense -- provided you believe the defn. of C makes sense.

after commas that didn't have any).

"What's New in Python ..." documents.

and introduces a new method .decode().

The major change is that strg.encode() will no longer try to convert
Unicode returns from the codec into a string, but instead pass along
the Unicode object as-is. The same is now true for all other codec
return types. The underlying C APIs were changed accordingly.

Note that even though this does have the potential of breaking
existing code, the chances are low since conversion from Unicode
previously took place using the default encoding which is normally
set to ASCII rendering this auto-conversion mechanism useless for
most Unicode encodings.

The good news is that you can now use .encode() and .decode() with
much greater ease and that the door was opened for better accessibility
of the builtin codecs.

As demonstration of the new feature, the patch includes a few new
codecs which allow string to string encoding and decoding (rot13,
hex, zip, uu, base64).

Written by Marc-Andre Lemburg. Copyright assigned to the PSF.

*are* obsolete; three variables and the maketrans() function are not
(yet) obsolete.

Add a compensating warnings.filterwarnings() call to test_strop.py.

Add this to the NEWS.

return a (C) long:  PyArg_ParseTuple and Py_BuildValue may not let us get
at the size_t we really want, but C int is clearly too small for a 64-bit
box, and both the start parameter and the return value should work for
large mapped files even on 32-bit boxes.  The code really needs to be
rethought from scratch (not by me, though ...).

the regression test is run in verbose mode.

elements when crunching a list, dict or tuple.  Now takes linear time
instead -- huge speedup for even moderately large containers, and the
code is notably simpler too.
Added some basic "is the output correct?" tests to test_pprint.

description, so that the introduction of complex is not a surprise.

This closes SF bug #423429.

Added a WITHOUT_FRAMEWORKS define to all the config files, so that on MacOS<=9 compiles use Universal Headers, not Carbon/Carbon.h.

lines between paragraphs in Mark Hammond's news item about the default
encoding in posixmodule.  Resist the temptation to reflow paragraphs.

Fix the Py_FileSystemDefaultEncoding checkin - declare the variable in a fileobject.h, and initialize it in bltinmodule.

1) it didn't obey the "start" parameter (and when it does, we must validate
   the value)
2) the return value needs to be an absolute index, rather than relative to
   some arbitrary point in the file

(checking CVS, it appears this method never worked; these changes bring it
 into line with typical .find() behavior)

Add support for Windows using "mbcs" as the default Unicode encoding when dealing with the file system.  As discussed on python-dev and in patch 410465.

to reason that me_key is much more likely to match the key we're looking
for than to match dummy, and if the key is absent me_key is much more
likely to be NULL than dummy:  most dicts don't even have a dummy entry.
Running instrumented dict code over the test suite and some apps confirmed
that matching dummy was 200-300x less frequent than matching key in
practice.  So this reorders the tests to try the common case first.
It can lose if a large dict with many collisions is mostly deleted, not
resized, and then frequently searched, but that's hardly a case we
should be favoring.