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.
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
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).
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. :-)
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).
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.
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.
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.
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.
Jack Jansen
Michael W. Hudson
Tim Peters
Mark Hammond
Skip Montanaro
Guido van Rossum
Jeremy Hylton
Barry Warsaw
Martin v. Löwis
Fred Drake
Neal Norwitz
Thomas Heller