backport tim_one's checkin of
revision 1.4 of CallTipWindow.py
SF bug 546078: IDLE calltips cause application error.
Assorted crashes on Windows and Linux when trying to display a very
long calltip, most likely a Tk bug. Wormed around by clamping the
calltip display to a maximum of 79 characters (why 79? why not ...).
backport tim_one's checkin of
revision 1.21 of test_mmap.py
SF bug 544733: Cygwin test_mmap fix for Python 2.2.1
Close a file before trying to unlink it, and apparently Cygwin needs
writes to an mmap'ed file to get flushed before they're visible.
Bugfix candidate, but I think only for the 2.2 line (it's testing
features that I think were new in 2.2).
Fred Drake [Wed, 21 Aug 2002 19:24:43 +0000 (19:24 +0000)]
Clarify that even though some of the relevant specifications define the
order in which form variables should be encoded in a request, a CGI script
should not rely on that since a client may not conform to those specs, or
they may not be relevant to the request.
Closes SF bug #596866.
Guido van Rossum [Tue, 20 Aug 2002 16:57:58 +0000 (16:57 +0000)]
Fix some endcase bugs in unicode rfind()/rindex() and endswith().
These were reported and fixed by Inyeol Lee in SF bug 595350. The
endswith() bug is already fixed in 2.3; I'll fix the others in
2.3 next.
Tim Peters [Mon, 19 Aug 2002 01:20:09 +0000 (01:20 +0000)]
A trip down memory lane. Barry checked in this test with 2.3-style
imports of test_support. That causes multiple copies of test_support
to get loaded, and the one used by test_base64.py didn't see the proper
value of verbose=False, so spewed output. That in turn apparenly caused
Barry to check in an expected-results output file, but a unitttest-based
test should never have one of those. I noticed this because, on Windows,
the final unittest output line contains the number of seconds needed to
run the test, and that varied on *some* runs when I tried it, causing
bogus test failures.
Anyway, this gets rid of the expected-output file again, and changes
the imports to work with 2.2's way of doing this.
Tim Peters [Mon, 19 Aug 2002 00:43:06 +0000 (00:43 +0000)]
SF bug 595919: popenN return only text mode pipes
popen2() and popen3() created text-mode pipes even when binary mode
was asked for. This was specific to Windows.
Modify splituser() method to allow an @ in the userinfo field.
Jeremy reported that this is not allowed by RFC 2396; however,
other tools support unescaped @'s so we should also.
Barry Warsaw [Thu, 15 Aug 2002 22:18:11 +0000 (22:18 +0000)]
Backport of fix for SF bug #595671 from Python 2.3cvs:
base64.decodestring('') should return '' instead of raising an
exception. The bug fix for SF #430849 wasn't quite right. This
closes SF bug #595671. I'll backport this to Python 2.2.
One addition here is that there was no test of the base64 module in
Python 2.2 cvs yet, so I added that too.
Guido van Rossum [Tue, 13 Aug 2002 10:07:17 +0000 (10:07 +0000)]
Backport:
Add an improvement wrinkle to Neil Schemenauer's change to int_mul
(rev. 2.79.6.3). The other type is only disqualified from sq_repeat when
it has the CHECKTYPES flag. This means that for extension types that
only support "old-style" numeric ops, such as Zope 2's ExtensionClass,
sq_repeat still trumps nb_multiply.
Only call sq_repeat if the object does not have a nb_multiply slot. One
example of where this changes behavior is when a new-style instance
defines '__mul__' and '__rmul__' and is multiplied by an int. Before
the change the '__rmul__' method is never called, even if the int is the
left operand.
Backport of 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.
Described responsibilty of weakly referenced extension types to initialize
the weakreflist to NULL in the constructor and to fill the tp_flags
slot with Py_TPFLAGS_HAVE_WEAKREFS. Closes SF bug 586583.
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. :-)
Fred Drake [Tue, 30 Jul 2002 17:52:05 +0000 (17:52 +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.
Fred Drake [Thu, 25 Jul 2002 21:11:41 +0000 (21:11 +0000)]
Small clarifications when referring to the sys.exc_* variables so that
readers are not given the wrong impression that they should be using those
on a regualar basis.
This closes SF bug #585598.
Tim Peters [Tue, 16 Jul 2002 20:09:08 +0000 (20:09 +0000)]
The atexit module effectively turned itself off if sys.exitfunc already
existed at the time atexit first got imported. That's a bug, and this
fixes it.
Also reworked test_atexit.py to test for this too, and to stop using
an "expected output" file, and to test what actually happens at exit
instead of just simulating what it thinks atexit will do at exit.
Jeremy Hylton [Tue, 16 Jul 2002 19:42:21 +0000 (19:42 +0000)]
The object returned by tp_new() may not have a tp_init.
If the object is an ExtensionClass, for example, the slot is not even
defined. So we must check that the type has the slot (implied by
HAVE_CLASS) before calling tp_init().
The test of httplib makes it difficult to maintain httplib. There are
two many idioms that pyclbr doesn't seem to understand, and I don't
understand how to update these tests to make them work.
Jeremy Hylton [Fri, 12 Jul 2002 14:23:43 +0000 (14:23 +0000)]
Backport changes.
Change _begin() back to begin().
Fix for SF bug 579107.
Fix for SF bug #432621: httplib: multiple Set-Cookie headers
Fix SF bug #575360
Handle HTTP/0.9 responses.
Tim Peters [Mon, 8 Jul 2002 22:30:52 +0000 (22:30 +0000)]
SF bug 578752: COUNT_ALLOCS vs heap types
Repair segfaults and infinite loops in COUNT_ALLOCS builds in the
presence of new-style (heap-allocated) classes/types.
Note: test_gc fails in a COUNT_ALLOCS build now, because it expects
a new-style class to get garbage collected.
Tim Peters [Mon, 8 Jul 2002 19:35:56 +0000 (19:35 +0000)]
PyNode_AddChild(): Backporting an aggressive over-allocation policy
when a parse node grows a very large number of children. This sidesteps
platform realloc() disasters on several platforms.
Fred Drake [Tue, 2 Jul 2002 22:35:02 +0000 (22:35 +0000)]
Update the documentation of the errors and failures attributes of the
TestResult object. Add an example of how to get even more information for
apps that can use it.
Closes SF bug #558278.
Tim Peters [Sun, 30 Jun 2002 18:48:53 +0000 (18:48 +0000)]
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
Fred Drake [Tue, 25 Jun 2002 17:18:48 +0000 (17:18 +0000)]
[Backport of recent changes to the SAX documentation.]
Add more links to the "See also" section for the xml.sax package.
Talk about interfaces rather than implementation classes where appropriate.
Add hyperlinks to make the documentation on the Attributes and AttributesNS
interfaces more discoverable.
Closes SF bug #484603.