week.

week.

functions.  In this case, calling dbm.open("foo", "c") actually creates a
file named "foo.db".

week.

should always have it.

Cater for that by working from sys.executable.

argv emulation (i.e. if the end user drops files and folders on the
applets these will show up in sys.argv) BuildApplet will add the required
code to the applet bundle, in __rawmain__.pyc.

This code is compiled from appletrawmain.py, it creates sys.argv, cleans
up most of the mess and executes either __main__.py or __main__.pyc.

actual script to run in case we are running from an applet. If we are indeed
running an applet we skip the normal option processing leaving it all to the
applet code.

This allows us to get use the normal python binary in the Python.app bundle,
giving us all the normal command line options through PythonLauncher while
still allowing Python.app to be used as the template for building applets.

Consequently, pythonforbundle is gone, and Mac/Python/macmain.c isn't used
on OSX anymore.

- The applet .rsrc file should be called python.rsrc, it is not based on the
  applet name.

[ 589427 ] standard include paths on command line

- "Open Document" appleevent is "odoc", not "open".

one .app nowadays) and fixed it to work.

during startup of a program. This module will replace the C code in
macgetargv.c so we can get rid of the special macmain.c for OSX
Python.app.

at random, and replaces the elements at those positions with new random
values.  I was pleasantly surprised by how fast this goes!  It's hard to
conceive of an algorithm that could special-case for this effectively.
Plus it's exactly what happens if a burst of gamma rays corrupts your
sorted database on disk <wink>.

 i    2**i  *sort  ...  %sort
15   32768   0.18  ...   0.03
16   65536   0.24  ...   0.04
17  131072   0.53  ...   0.08
18  262144   1.17  ...   0.16
19  524288   2.56  ...   0.35
20 1048576   5.54  ...   0.77

for Py_Main().

Thanks to Kalle Svensson and Skip Montanaro for the patches.

and age of rampant computer breakins I imagine there are plenty of systems
with telnet disabled.  Successful check of at least one getservbyname() call
is required for success

  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.