This is a verifier for the binary code used by the _sre module (this
is often called bytecode, though to distinguish it from Python bytecode
I put it in quotes).

I wrote this for Google App Engine, and am making the patch available as
open source under the Apache 2 license.  Below are the copyright
statement and license, for completeness.

# Copyright 2008 Google Inc.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

It's not necessary to include these copyrights and bytecode in the
source file.  Google has signed a contributor's agreement with the PSF
already.

If a PyTokenizer_FromString() is called with an empty string, the
tokenizer's line_start member never gets initialized.  Later, it is
compared with the token pointer 'a' in parsetok.c:193 and that behavior
can result in undefined behavior.

Bug 3228: take a test from Niels Gustaebel's patch, and based on his patch, check for having os.stat available

changes are needed once some decisions are made, but this is the work up to this
point.

long raise ValueError instead of returning 0.  Also, change the error
message for conversion of an infinity to an integer, replacing 'long' by
'integer', so that it's appropriate for both long(float('inf')) and
int(float('inf')).

warnings under -3.

Issue 643841: better documentation of the special method lookup process, especially for new-style classes. Also removes the warnings about not being authoritative for new-style classes - the language reference actually covers those fairly well now (albeit in a fashion that isn't always particularly easy to follow).

key list data structure in the thread startup path.

This change is a companion to r60148 which already successfully dealt with a
similar issue on thread shutdown.

In particular this loop has been observed happening from this call path:
 #0  in find_key ()
 #1  in PyThread_set_key_value ()
 #2  in _PyGILState_NoteThreadState ()
 #3  in PyThreadState_New ()
 #4  in t_bootstrap ()
 #5  in pthread_start_thread ()

I don't know how this happens but it does, *very* rarely.  On more than
one hardware platform.  I have not been able to reproduce it manually.
(A flaky mutex implementation on the system in question is one hypothesis).

As with r60148, the spinning we managed to observe in the wild was due to a
single list element pointing back upon itself.

names with docstring.

and add corresponding tests.
Possible 2.5 backport candidate

of using pipes that cause deadlocks.

while running under -3.

running under -3.

  argument in python 2.5, this broke code that subclassed Popen to include its
  own poll method.  Fixed my moving _deadstate to an _internal_poll method.

warnings when run under -3.

warnings triggered under -3.

package, when run under -3, about using <>.

under -3 through test_xmlrpc.

move from list.sort(cmp=) to key=.

cookielib.