us to completely decouple the framework from the executable, so we
  can use a two-level namespace.
- Do framework builds with a twolevel namespace.
- Reorganized the code that creates the minimal framework in the build
  directory, to make it more robust against incomplete frameworks (from
  earlier aborted builds, or builds of previous Python versions).

be invoked by PythonLauncher when needed.

Also changed the names of various variables in the Makefile to match
what the main Makefile has.

PythonLauncher.app has taken that responsibility over.

longer to run than normal.  A profiler run showed that this was due to
PyFrame_New() taking up an unreasonable amount of time.  A little
thinking showed that this was due to the while loop clearing the space
available for the stack.  The solution is to only clear the local
variables (and cells and free variables), not the space available for
the stack, since anything beyond the stack top is considered to be
garbage anyway.  Also, use memset() instead of a while loop counting
backwards.  This should be a time savings for normal code too!  (By a
probably unmeasurable amount. :-)

dragging or double-clicking the script.

The __delete__ method wrapper for descriptors was not supported

(I added a test, too.)

2.2 bugfix candidate.

using sort() with comparison functions (it made reference to the non-
existent "builtin-in function sort()").

BTW, I changed list.sort's docstring to contain the word "stable" -- the
easiest way to tell whether a particular Python version's sort *is* stable
is to look for "stable" in the docstring.  I'm not sure whether to
advertise this <wink>.

in the stability tests.

Bizarre:  this takes 11x longer to run if and only if test_longexp is
run before it, on my box.  The bigger REPS is in test_longexp, the
slower this gets.  What happens on your box?  It's not gc on my box
(which is good, because gc isn't a plausible candidate here).

The slowdown is massive in the parts of test_sort that implicitly
invoke a new-style class's __lt__ or __cmp__ methods.  If I boost
REPS large enough in test_longexp, even the test_sort tests on an array
of size 64 visibly c-r-a-w-l.  The relative slowdown is even worse in
a debug build.  And if I reduce REPS in test_longexp, the slowdown in
test_sort goes away.

test_longexp does do horrid things to Win98's management of user
address space, but I thought I had made that a whole lot better a month
or so ago (by overallocating aggressively in the parser).

stuff into code comments, and lots of it is going to be useful again (but
hard to predict exactly which parts of it ...).

arguments correctly too.

+ Don't change the arglist requirements.
+ Give the wrapper the same docstring as _socket.socket (it didn't
  have any docstring).

1.6, and pierslauder didn't respond to email about it on Monday.

thinking that he was running his new test by running "make test".
Also, I can't get this to fail any more.  Your turn. :-)

If the long is large enough, the return value will be a negative int.
In this case, calling the function a second time won't return the
original value passed in.

- Build PythonLauncher.app and PythonIDE.app as well as Python.app.

optimal, especially if Terminal wasn't running yet, but it works.

[ 561724 ] README additions for Cray T3E

Lightly edited by me.

imports of test modules now import from the test package.  Other
related oddities are also fixed (like DeprecationWarning filters that
weren't specifying the full import part, etc.).  Also did a general
code cleanup to remove all "from test.test_support import *"'s.  Other
from...import *'s weren't changed.

pass -DHAVE_CONFIG_H to CC, and that symbol isn't used any more.

The "Matching vs. Searching" Info node is unreachable from the Info
program (but is fine in Emacs's Info mode). This patch seems to fix
it.  This is the only occurrence where the info reader fails, so
probably it could be addressed in the python docs as a workaround.
Forwarded the report to the info maintainer.

Clarify LLTRACE description.  It was introduced in 1992, revision 2.20 of
ceval.c, well before Python 1.0!

Revert changes to use PyArg_Parse(), so any sequence will continue to work -- Spotted by Just van Rossum

See there for a description.

Added test case.

Bugfix candidate for 2.2.x, not sure about previous versions:
probably low priority, because virtually no one runs debug builds.

doubleclicks a .py, .pyw or .pyc file. It runs the file by invoking the
relevant interpreter (either the command line Python in a terminal window
or a Python.app for GUI-based scripts). Interpreter to use and the options
to pass are settable through preferences.

If PythonLauncher wasn't running it does its thing for one script and exits.
If it was manually started before a dialog is presented where the user
can set the options to use, etc.

To be done:
- option-drag/doubleclick should always open the interactive dialog
- Terminal-window isn't done yet
- Should be reimplemented in Python, but pyobjc isn't part of the core.
- Various menu entries should be disabled.

This patch fixes make install for Cygwin. Specifically,
it reverts to the previous behavior:

o install libpython$(VERSION)$(SO) in $(BINDIR)
o install $(LDLIBRARY) in $(LIBPL)

It also begins to remove Cygwin's dependency on
$(DLLLIBRARY) which I hope to take advantage of
when I attempt to make Cygwin as similar as possible
to the other Unix platforms (in other patches).

I tested this patch under Red Hat Linux 7.1 without
any ill effects.

BTW, I'm not the happiest using the following
test for Cygwin:

test "$(SO)" = .dll

I'm willing to update the patch to use:

case "$(MACHDEP)" in cygwin*

instead, but IMO that will look uglier.

[ 587875 ] crash on deleting extended slice

The array code got simpler, always a good thing!

 PyErr_SetExcFromWindowsErr(), PyErr_SetExcFromWindowsErrWithFilename().

Similar to PyErr_SetFromWindowsErrWithFilename() and
PyErr_SetFromWindowsErr(), but they allow to specify
the exception type to raise. Available on Windows.

See SF patch #576458.