| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
instead of into a list for a bit of speed/space savings. Reopened the
bug report too (628246), as I'm unclear on why we don't sort out the
cause of the TypeError instead.
|
|
|
|
|
|
|
|
| |
The _update method detected mutable elements by trapping TypeErrors.
Unfortunately, this masked useful TypeErrors raised by the iterable
itself. For cases where it is possible for an iterable to raise
a TypeError, the iterable is pre-converted to a list outside the
try/except so that any TypeErrors propagate through.
|
|
|
|
|
|
|
|
|
|
| |
dialogs are now stored in Mac/Lib, and loaded on demand through macresource.
Not only does this simplify a MacPython based on Apple's Python, but
it also makes Mac error codes come out symbolically when running command
line python (if you have Mac/Lib in your path).
The resource files are copied from Mac/Resources. The old ones will disappear
after the OS9 build procedure has been adjusted.
|
|
|
|
|
|
|
|
|
|
| |
The errors attribute can be changed after the reader/writer
is created.
For encoding there are two additional errors values:
"xmlcharrefreplace" and "backslashreplace".
These values can be extended via register_error().
|
| |
|
|
|
|
|
| |
dir(xrange(10))
xrange(10).__getitem__(4)
|
|
|
|
|
|
|
| |
always available on Windows NT. When the function cannot be loaded,
get_special_folder_path raises OSError, "function not available".
Compiled the exe, and rebuilt bdist_wininst.py.
|
|
|
|
| |
See http://mail.python.org/pipermail/distutils-sig/2002-November/003039.html
|
|
|
|
| |
(Hope the markup is ok).
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug happened because: 1) the scanner_search and scanner_match methods
were not checking the buffer limits before increasing the current pointer;
and 2) SRE_SEARCH was using "if (ptr == end)" as a loop break, instead of
"if (ptr >= end)".
* Modules/_sre.c
(SRE_SEARCH): Check for "ptr >= end" to break loops, so that we don't
hang forever if a pointer passing the buffer limit is used.
(scanner_search,scanner_match): Don't increment the current pointer
if we're going to pass the buffer limit.
* Misc/NEWS
Mention the fix.
|
| |
|
| |
|
|
|
|
| |
[SF patch 634250 -- that was an IDLEFORK patch.]
|
|
|
|
|
|
|
|
|
|
|
| |
* Lib/distutils/command/bdist_rpm.py
(bdist_rpm.initialize_options): Included verify_script attribute.
(bdist_rpm.finalize_package_data): Ensure that verify_script is a filename.
(bdist_rpm._make_spec_file): Included verify_script in script_options
tuple.
* Misc/NEWS
Mention change.
|
|
|
|
|
|
| |
and StreamRecoder.
This closes SF bug #634246.
|
|
|
|
|
|
| |
Also remove the 512 character limitation for int(u"...") and long(u"...").
This closes SF bug #629989.
|
| |
|
|
|
|
| |
Fixes a test failure on 64 bit platforms (I hope).
|
| |
|
|
|
|
| |
now called MinGW
|
|
|
|
| |
Make docs accurate; getch() in nodelay mode returns -1
|
|
|
|
|
|
| |
Make keyname raise ValueError if passed -1, avoiding a segfault
Make getkey() match the docs and raise an exception in nodelay mode
The return type of getch() is int, not chtype
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
from Greg Chapman.
* Modules/_sre.c
(lastmark_restore): New function, implementing algorithm to restore
a state to a given lastmark. In addition to the similar algorithm used
in a few places of SRE_MATCH, restore lastindex when restoring lastmark.
(SRE_MATCH): Replace lastmark inline restoring by lastmark_restore(),
function. Also include it where missing. In SRE_OP_MARK, set lastindex
only if i > lastmark.
* Lib/test/re_tests.py
* Lib/test/test_sre.py
Included regression tests for the fixed bugs.
* Misc/NEWS
Mention fixes.
|
|
|
|
| |
being on a case-insensitive filesystem, not the source directory.
|
|
|
|
| |
a caret in this case too.
|
| |
|
|
|
|
| |
text is the search term.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
pretty-prints the value of its expression argument.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
where in lax parsing, the first non-header line after a header block
(e.g. the first line not containing a colon, and not a continuation),
can be treated as the first body line, even without the RFC mandated
blank line separator.
rfc822 had this behavior, and I vaguely remember problems with this,
but can't remember details. In any event, all the tests still pass,
so I guess we'll find out. ;/
This patch works by returning the non-header, non-continuation line
from _parseheader() and using that as the first header line prepended
to fp.read() if given. It's usually None.
We use this approach instead of trying to seek/tell the file-like
object.
|
|
|
|
|
|
| |
separating blank line between a header block and body text.
Tests both lax and strict parsing.
|
|
|
|
| |
body. A test message for SF bug #633527.
|
|
|
|
|
| |
#631350, where a subobject in a multipart/digest isn't a
message/rfc822.
|
|
|
|
|
|
|
|
|
|
| |
multipart/digest isn't a message/rfc822. This is legal, but counter
to recommended practice in RFC 2046, $5.1.5.
The fix is to look at the content type after setting the default
content type. If the maintype is then message or multipart, attach
the parsed subobject, otherwise use set_payload() to set the data of
the other object.
|
|
|
|
|
| |
multipart/digest isn't a message/rfc822. This is legal, but counter
to recommended practice in RFC 2046, $5.1.5.
|
|
|
|
|
|
|
|
|
|
| |
The last round boosted "the limit" from 2GB to 4GB. This round gets
rid of the 4GB limit. For files > 4GB, gzip stores just the last 32
bits of the file size, and now we play along with that too. Tested
by hand (on a 6+GB file) on Win2K.
Boosting from 2GB to 4GB was arguably enough "a bugfix". Going beyond
that smells more like "new feature" to me.
|
| |
|
| |
|
| |
|