3.1.2 Release Blocker

If Python 3.1.2rc1 is built with openssl 0.9.7 (which lacks support for sha256 and sha512), hashlib is supposed to substitute use of built-in C implementations for them.  With 3.1.2rc1, the "built-in" versions are available via hashlib.new() but not by their "always available" constructor functions.  This causes major test failures in test_hashlib, test_hmac, and test_pep247.  The problem is critical for OS X installer builds because both OS X 10.4 and 10.5 ship with openssl 0.9.7 but the problem should show up on other platforms using 0.9.7 as well.

The following comparison between 2.6.5rc2 and 3.1.2rc1 demonstrates the problem:

Python 2.6.5rc2 (release26-maint, Mar 15 2010, 00:15:31) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> hashlib.new('sha1')
<sha1 HASH object @ 0xd0560>
>>> hashlib.sha1()
<sha1 HASH object @ 0xd04c0>
>>> hashlib.new('sha512')
<_sha512.sha512 object at 0x6b3a0>
>>> hashlib.sha512()
<_sha512.sha512 object at 0x6b480>
>>> dir(hashlib)
['__builtins__', '__doc__', '__file__', '__get_builtin_constructor', '__hash_new', '__name__', '__package__', '__py_new', '_hashlib', 'md5', 'new', 'sha1', 'sha224', 'sha256', 'sha384', 'sha512']
>>> dir(_hashlib)
['__doc__', '__file__', '__name__', '__package__', 'new', 'openssl_md5', 'openssl_sha1', 'openssl_sha224', 'openssl_sha256', 'openssl_sha384', 'openssl_sha512']
 
Python 3.1.2rc1+ (release31-maint, Mar 17 2010, 12:38:35) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> hashlib.new('sha1')
<sha1 HASH object @ 0x11d740>
>>> hashlib.sha1()
<sha1 HASH object @ 0x11da20>
>>> hashlib.new('sha512')
<_sha512.sha512 object at 0x9d640>
>>> hashlib.sha512()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'sha512'
>>> dir(hashlib)
['__builtins__', '__doc__', '__file__', '__get_builtin_constructor', '__hash_new', '__name__', '__package__', '__py_new', '_hashlib', 'md5', 'new', 'sha1']
>>> dir(_hashlib)
['__doc__', '__file__', '__name__', '__package__', 'new', 'openssl_md5', 'openssl_sha1']

It appears the cause of the problem was a mismatch of merges to 3.1.  In response to Issue6281, some major cleanup to hashlib.py went into trunk in r74479 and py3k in r74482 but was not backported to 2.6 or 3.1.  Later, r77608 to trunk added some conditional compilation tests in _hashopenssl.c based on openssl version, which was fine on top of the hashlib.py cleanup.  Still later, r77408 was auto-merged to py3k in r77937 (OK) *and* 3.1 in r77938 which is NOT OK, because the old hashlib.py in (3.1 and 2.6) indirectly depends on all of the openssl_* names being defined in _hashlib.

Probably the best solution for 3.1 at this point is to revert the conditional tests in _hashopenssl.c.

Should be: "Still later, r77608 was auto-merged [...]"

Nice catch! Reverted in r79054.

Fix verified.