and this broke a Zope "pipelining" test which read multiple responses
from the same connection (this attaches a new file object to the
socket for each response). Added a test for this too.
(I want to do some code cleanup too, but I thought I'd first fix
the problem with as little code as possible, and add a unit test
for this case. So that's what this checkin is about.)
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.)
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>.
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.
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).
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
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).
Guido van Rossum
Raymond Hettinger
Barry Warsaw
Fred Drake
Kurt B. Kaiser
Martin v. Löwis
Tim Peters
Andrew MacIntyre
Piers Lauder
Skip Montanaro