Mention list.sort()
Document heapq module
Add PEP263 section (not sure I really understand the PEP's effect on 8-bit
   strings, though -- will have to experiment with it)

SF patch #591305 Documentation err in bytecode defs

We only need to check for StopIteration here.

Patch by Ronald Oussoren: if there's a .lproj in the extras list also
check whether it contains a .nib, and do the Cocoa song and dance if
it does.

In copy() don't try to obtain an FSSpec until we know the destination
exists. Partial fix for #585923.

Be a lot less verbose by default.

Better output for errors, and some progress reports.
Handle the two modules with non-standard scanner module names.

Fixed the last two bgen-based modules to be buildable on OSX.

Initial prototype of framer: a tool to build the frame for extension modules.

Remove function definition from cStringIO.h.

xxxPyCObject_Import() seems to be a copy of PyCObject_Import().

Since the errno module is needed by os._execvpe(), and that is used by the
setup.py (indirectly) script to build the standard dynamically loaded
modules, the errno module is being made static so it will always be
available.
Closes SF bug #591205 (needed on trunk only).

SF patch 590294: os._execvpe security fix (Zack Weinberg).

SF patch 590294: os._execvpe security fix (Zack Weinberg).

1) Do not attempt to exec a file which does not exist
just to find out what error the operating system
returns. This is an exploitable race on all platforms
that support symbolic links.

2) Immediately re-raise the exception if we get an
error other than errno.ENOENT or errno.ENOTDIR. This
may need to be adapted for other platforms.

(As a security issue, this should be considered for 2.1
and 2.2 as well as 2.3.)

Enable building of Carbon toolbox modules with unix-Python.

Got rid of staticforward.

This can now run under unix-Python too. You have to pass the folder
to search on the command line in that case.

Fixed to run better in unix-Python, and to cater for bgenlocations
possibly being missing.

Typo:  "now" --> "the new"

IDLE support for PEP 263.

Moved bgenlocations to the Mac/Lib directory. Not perfect, but better than
where it was: it is really a configuration file, not a normal module.

By moving it into Mac/Lib we can now also store the location of bgen
itself in there, which is needed because bgen isn't installed.

Patch #590913: PEP 263 support.

Use ascii_letters to avoid UnicodeErrors.

Add a small description of PEP 263.

Added a cast to shut up a compiler warning.

Renamed Py_Main to PyMac_Main as it has a different signature than the "normal" Py_Main, and that signature has appeared in a .h file.

Added _IBCarbon module.

SF 582071 clarified the .split() method's docstring to note that sep=None
will trigger splitting on any whitespace.

Note that True and False are pickable objects

GvR provided solution to the socket rebinding timeout problem.

M PyShell.py
M rpc.py
M run.py

Add 1 to lineno in deprecation warning. Fixes #590888.

Test whether a Cyrillic text correctly appears in a Unicode literal.

We don't really need the name of the test in the "test skipped" msg, and
having it there causes the line to wrap.

Oops!  Forgot the closing paren.

Finally got around to figuring out and documenting why this test fails
on Windows.  The test_sequence() ERROR is easily repaired if we're
willing to add an os.unlink() line to mhlib's updateline().  The
test_listfolders FAIL I gave up on -- I don't remember enough about Unix
link esoterica to recall why a link count of 2 is something a well-
written program should be keenly interested in <wink>.

Build the _IBCarbon module.

The definitions for IBCarbonRuntime.h

Updated to something that works on my system, and regenerated module.

Specify pathnames in a way that works on both OS9 and OSX.
You'll still have to manually edit it, though...

Use universal newline input when scanning header files.

Donovan Preston's interface to IBCarbon, allowing you to use Interface
Builder carbon NIB files from Python. As-is, I may need to twiddle a few
things as he donated this long ago.

Donovan is now one of the four people in the world who know how to drive
bgen!

Changes to the OSX section:
- steer people away from installing with sudo
- warn that fink-installed software may cause trouble
- explain why you might want a framework build and point people to
  Mac/OSX/README.

Use the -n option of ln in stead of -h, as it also works with other ln's
people may have (fink, gnu).

small speedup for constant and name access
see sf #506436

Make pgen compile with pydebug. Duplicate normalized names, as it may
be longer than the old string.

Group statements properly.

Repaired a fatal compiler error in the debug build:  it's not clear what
this was trying to assert, but the name it referenced didn't exist.

Squash compiler wng about signed-vs-unsigned mismatch.

Sped the usual case for sorting by calling PyObject_RichCompareBool
directly when no comparison function is specified.  This saves a layer
of function call on every compare then.  Measured speedups:

 i    2**i  *sort  \sort  /sort  3sort  +sort  %sort  ~sort  =sort  !sort
15   32768  12.5%   0.0%   0.0% 100.0%   0.0%  50.0% 100.0% 100.0% -50.0%
16   65536   8.7%   0.0%   0.0%   0.0%   0.0%   0.0%  12.5%   0.0%   0.0%
17  131072   8.0%  25.0%   0.0%  25.0%   0.0%  14.3%   5.9%   0.0%   0.0%
18  262144   6.3% -10.0%  12.5%  11.1%   0.0%   6.3%   5.6%  12.5%   0.0%
19  524288   5.3%   5.9%   0.0%   5.6%   0.0%   5.9%   5.4%   0.0%   2.9%
20 1048576   5.3%   2.9%   2.9%   5.1%   2.8%   1.3%   5.9%   2.9%   4.2%

The best indicators are those that take significant time (larger i), and
where sort doesn't do very few compares (so *sort and ~sort benefit most
reliably).  The large numbers are due to roundoff noise combined with
platform variability; e.g., the 14.3% speedup for %sort at i=17 reflects
a printed elapsed time of 0.18 seconds falling to 0.17, but a change in
the last digit isn't really meaningful (indeed, if it really took 0.175
seconds, one electron having a lazy nanosecond could shift it to either
value <wink>).  Similarly the 25% at 3sort i=17 was a meaningless change
from 0.05 to 0.04.  However, almost all the "meaningless changes" were
in the same direction, which is good.  The before-and-after times for
*sort are clearest:

before after
  0.18  0.16
  0.25  0.23
  0.54  0.50
  1.18  1.11
  2.57  2.44
  5.58  5.30

Patch #534304: Implement phase 1 of PEP 263.

Add encoding declaration.

Add encoding declaration.

Remove a syntax error in the example, spotted by Walter Hofman.

Always link libpython.so with LIBS. Fixes #589422.

Add trace_frame. Fixes #534864. Backported to 2.2.

Add recursion counter for pickling. Fixes #576084.
2.2 bugfix candidate (may cause RuntimeError for applications that
currently work fine).

OS/2 EMX now supported

I don't know what's going on with this test, but the last change from
Piers obviously couldn't have passed on any platform.  Fiddling it so it
works (for a meaning of "works" no stronger than "doesn't fail" <wink>).

SF patch #578297:

Change the parser and compiler to use PyMalloc.

Only the files implementing processes that will request memory
allocations small enough for PyMalloc to be a win have been
changed, which are:-
 - Python/compile.c
 - Parser/acceler.c
 - Parser/node.c
 - Parser/parsetok.c

This augments the aggressive overallocation strategy implemented by
Tim Peters in PyNode_AddChild() [Parser/node.c], in reducing the
impact of platform malloc()/realloc()/free() corner case behaviour.
Such corner cases are known to be triggered by test_longexp and
test_import.

Jeremy Hylton, in accepting this patch, recommended this as a
bugfix candidate for 2.2.  While the changes to Python/compile.c
and Parser/node.c backport easily (and could go in), the changes
to Parser/acceler.c and Parser/parsetok.c require other not
insignificant changes as a result of the differences in the memory
APIs between 2.3 and 2.2, which I'm not in a position to work
through at the moment.  This is a pity, as the Parser/parsetok.c
changes are the most important after the Parser/node.c changes, due
to the size of the memory requests involved and their frequency.

- comment improvement
- implement viable library search routine for EMX

add parameter missing following Jeremy's compiler class refactoring

Add two reminders

Document that --enable-shared puts PIC objects into the static libpython.
Fixes #589429.

Mkdirs() failed when provided with unix pathnames. Fixed.

_siftup():  __le__ is now the only comparison operator used on array
elements.

Document new heapreplace() function.

Document new heapify() function.

Revert last checkin.  Man, that was stupid.

Another fix for:

[ 589427 ] standard include paths on command line

_ssl still got /usr/include on the command line.

revert to version 1.2

Added new heapreplace(heap, item) function, to pop (and return) the
currently-smallest value, and add item, in one gulp.  See the second
N-Best algorithm in the test suite for a natural use.

Large code rearrangement to use better algorithms, in the sense of needing
substantially fewer array-element compares.  This is best practice as of
Kntuh Volume 3 Ed 2, and the code is actually simpler this way (although
the key idea may be counter-intuitive at first glance!  breaking out of
a loop early loses when it costs more to try to get out early than getting
out early saves).
Also added a comment block explaining the difference and giving some real
counts; demonstrating that heapify() is more efficient than repeated
heappush(); and emphasizing the obvious point thatlist.sort() is more
efficient if what you really want to do is sort.

SF bug 590366:  Small typo in listsort:ParseTuple
The PyArg_ParseTuple() error string still said "msort".  Changed to "sort".

Remove cut 'n paste silliness.

Minor fiddling, including a simple class to implement a heap iterator
in the test file.  I have docs for heapq.heapify ready to check in, but
Jack appears to have left behind a stale lock in the Doc/lib directory.

Added an icon for .pyw files.

An icon for .pyw files. Yes, it's lousy, I know....

Augment credits.

Hmm!  I thought I checked this in before!  Oh well.

Added new heapify() function, which transforms an arbitrary list into a
heap in linear time; that's a fundamental tool for using heaps in real
life <wink>.

Added heapyify() test.  Added a "less naive" N-best algorithm to the test
suite, and noted that this could actually go much faster (building on
heapify()) if we had max-heaps instead of min-heaps (the iterative method
is appropriate when all the data isn't known in advance, but when it is
known in advance the tradeoffs get murkier).

Build the IDE last, as it may fail because of waste missing.

Added a lot more information on framework builds, the various .app's,
etc. Still not enough, probably, but better than what we had.

Updated for the new path to Python.app.

When building the IDE check that waste is available, to forestall
surprises later (the IDE won't work without waste).

Add a PEP-263-style encoding turd^H^H^H^Hdeclaration, because there's
a c-cedilla in one of the docstrings.

Fix ref(), proxy() docstrings, based on comments from David Abrahams.

heappop():  Added comments; simplified and sped the code.

Minor markup changes.

heappop():  Use "while True" instead of "while 1".

check_invariant():  Use the same child->parent "formula" used by heapq.py.

Don't use true division where int division was intended.  For that matter,
don't use division at all.

Add a comment showing how one of the macros should be used.

Adding the heap queue algorithm, per discussion in python-dev last
week.

Add heapq module docs to the dependency information.

Adding the heap queue algorithm, per discussion in python-dev last
week.

Add docs for heapq.py.

indicate that 'b' is added to the mode flag if not given

add #include branch for compilation with Berkeley DB

catch the situation where Berkeley DB is used to emulate dbm(3) library
functions.  In this case, calling dbm.open("foo", "c") actually creates a
file named "foo.db".

regression test for the whichdb module

Add Kevin O'Connor, author of the heapq code.

Adding the heap queue algorithm, per discussion in python-dev last
week.