Update the URL for getting zlib, and update the minimal required
version to 1.1.4 (because of the 1.1.3 security problem). Also
replace a funny use of line.find() with line.startswith().
Document file.next(). Mark xreadlines obsolete (both method and
module). (One thing remains to be done: the gzip class has an
xreadline method; this ought to be replaced by an iterator as well.)
SF patch 580331 by Oren Tirosh: make file objects their own iterator.
For a file f, iter(f) now returns f (unless f is closed), and f.next()
is similar to f.readline() when EOF is not reached; however, f.next()
uses a readahead buffer that messes up the file position, so mixing
f.next() and f.readline() (or other methods) doesn't work right.
Calling f.seek() drops the readahead buffer, but other operations
don't.
The real purpose of this change is to reduce the confusion between
objects and their iterators. By making a file its own iterator, it's
made clearer that using the iterator modifies the file object's state
(in particular the current position).
A nice side effect is that this speeds up "for line in f:" by not
having to use the xreadlines module. The f.xreadlines() method is
still supported for backwards compatibility, though it is the same as
iter(f) now.
(I made some cosmetic changes to Oren's code, and added a test for
"file closed" to file_iternext() and file_iter().)
Jack Jansen [Tue, 6 Aug 2002 13:40:31 +0000 (13:40 +0000)]
In the altbininstall target, which is the first subtarget for "make install",
if we are running in an OSX framework enabled build directory, test that
the framework infrastructure exists. This catches the very common
error of doing "make install" in stead of "make frameworkinstall".
Jack Jansen [Tue, 6 Aug 2002 12:59:44 +0000 (12:59 +0000)]
Patch #567296 by Pim Buurman, slightly modified by me so it can be disabled
at compile time: use PBGetCatInfoSync() to get FInfo data in stead of
GetFInfo. The latter doesn't work for folders. The former does, at
least on OSX, and insofar the info makes sense for a folder.
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)
Fred Drake [Mon, 5 Aug 2002 18:06:17 +0000 (18:06 +0000)]
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).
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.)
Tim Peters [Sun, 4 Aug 2002 22:35:31 +0000 (22:35 +0000)]
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>.
Jack Jansen [Sun, 4 Aug 2002 21:34:24 +0000 (21:34 +0000)]
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!
Jack Jansen [Sun, 4 Aug 2002 21:19:55 +0000 (21:19 +0000)]
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.
Tim Peters [Sun, 4 Aug 2002 17:47:26 +0000 (17:47 +0000)]
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:
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
Tim Peters [Sun, 4 Aug 2002 06:53:18 +0000 (06:53 +0000)]
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>).
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.
Tim Peters [Sat, 3 Aug 2002 10:10:10 +0000 (10:10 +0000)]
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.
Tim Peters [Sat, 3 Aug 2002 09:56:52 +0000 (09:56 +0000)]
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.
Tim Peters [Sat, 3 Aug 2002 02:11:26 +0000 (02:11 +0000)]
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.
Tim Peters [Fri, 2 Aug 2002 21:48:06 +0000 (21:48 +0000)]
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).