Skip Montanaro [Fri, 2 Aug 2002 17:12:15 +0000 (17:12 +0000)]
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".
Jack Jansen [Fri, 2 Aug 2002 14:57:43 +0000 (14:57 +0000)]
Final step in making applets first-class citizens: if the applet wants
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.
Jack Jansen [Fri, 2 Aug 2002 14:11:24 +0000 (14:11 +0000)]
Added one call to Py_Main(), for OSX framework builds only, that will get the
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.
Jack Jansen [Fri, 2 Aug 2002 14:04:15 +0000 (14:04 +0000)]
- Slightly better error message in case of syntax errors in the script.
- The applet .rsrc file should be called python.rsrc, it is not based on the
applet name.
Jack Jansen [Fri, 2 Aug 2002 11:12:15 +0000 (11:12 +0000)]
Construct a sys.argv from the initial AppleEvent sent by the finder
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.
Tim Peters [Fri, 2 Aug 2002 05:46:09 +0000 (05:46 +0000)]
New test %sort. This takes a sorted list, picks 1% of the list positions
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>.
Skip Montanaro [Fri, 2 Aug 2002 02:19:46 +0000 (02:19 +0000)]
modify testGetServByName so it tries a few different protocols. In this day
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
Jack Jansen [Thu, 1 Aug 2002 21:57:49 +0000 (21:57 +0000)]
- Get _environ through the NSEnviron call in a MacOSX framework. This allows
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).
Tim found that once test_longexp has run, test_sort takes very much
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. :-)
Tim Peters [Thu, 1 Aug 2002 03:10:45 +0000 (03:10 +0000)]
Added new footnote about list.sort() stability. Repaired footnote about
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>.
Tim Peters [Thu, 1 Aug 2002 02:23:06 +0000 (02:23 +0000)]
New test for sorting sanity. Note that this will fail in earlier Pythons,
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).
Tim Peters [Thu, 1 Aug 2002 00:59:42 +0000 (00:59 +0000)]
Checking in the doc file for "timsort". There's way too much here to
stuff into code comments, and lots of it is going to be useful again (but
hard to predict exactly which parts of it ...).
Tim Peters [Wed, 31 Jul 2002 17:32:11 +0000 (17:32 +0000)]
For platforms (like Windows) that wrap _socket.socket:
+ Don't change the arglist requirements.
+ Give the wrapper the same docstring as _socket.socket (it didn't
have any docstring).
Enable test_socket again, if only to prevent mistakes like Jeremy
thinking that he was running his new test by running "make test".
Also, I can't get this to fail any more. Your turn. :-)
Jeremy Hylton [Wed, 31 Jul 2002 15:57:39 +0000 (15:57 +0000)]
Repair testNtoH for large long arguments.
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.
Barry Warsaw [Tue, 30 Jul 2002 23:27:12 +0000 (23:27 +0000)]
Complete the absolute import patch for the test suite. All relative
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.
Fred Drake [Tue, 30 Jul 2002 17:51:20 +0000 (17:51 +0000)]
SF patch #581414: info reader bug
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.
Jack Jansen [Mon, 29 Jul 2002 21:36:35 +0000 (21:36 +0000)]
First stab at the launcher application. This will be run when the user
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.
Jason Tishler [Mon, 29 Jul 2002 16:18:23 +0000 (16:18 +0000)]
Patch #553702: Cygwin make install patch
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:
Thomas Heller [Mon, 29 Jul 2002 14:27:41 +0000 (14:27 +0000)]
New functions for extension writers on Windows:
PyErr_SetExcFromWindowsErr(), PyErr_SetExcFromWindowsErrWithFilename().
Similar to PyErr_SetFromWindowsErrWithFilename() and
PyErr_SetFromWindowsErr(), but they allow to specify
the exception type to raise. Available on Windows.
Mark Hammond [Mon, 29 Jul 2002 13:42:14 +0000 (13:42 +0000)]
Excise DL_IMPORT/EXPORT from object.h, and related files. This patch
also adds 'extern' to PyAPI_DATA rather than at each declaration, as
discussed with Tim and Guido.