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).

    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.