Here is the follow-up to issue #4818. The patches attached allow the
built-in SHA modules to release the GIL.

Also the build-in SHA modules will now no longer accept "s#" as input.
Input is parsed just as in the openssl-driven classes where
unicode-objects are explicitly rejected.


The built-in hash modules have been not quite beautiful before even more
code is now copy & pasted between them. Is there any interest in
refactoring all those modules? AFAIK _sha1 and such are only used by
hashlib.py ...

This patch is a duplicate of #3745.

Oops, it's not a duplicate /o\ But it may solves #3745 (reject unicode 
in sha256).

sha1module_small_locks.diff patch is very similar to the changes made 
in #4751, except:
 - SHA1_GIL_MINSIZE is 8192 whereas HASHLIB_GIL_MINSIZE is 2048
 - There is no test for PyThread_allocate_lock() failure

Instead of copy/paste code in hashlib, sha1, sha256 and sha512 (4 
modules), can't we share some constants, functions or macros? 
Examples:
 - the GIL minimum size constant
 - the long MY_GET_BUFFER_VIEW_OR_ERROUT macro (which can be a 
function)

And about sha, why using 3 files for sha? Are the source code so 
different? In the GNU libc, they use "template" files (it's possible 
even with the C language using the preprocessor!): strtof(), strtod() 
and strtold() share 99% of the source code. Interesting content of 
strtof.c :
----
#define	FLOAT		float
#define	FLT		FLT
#ifdef USE_WIDE_CHAR
#define STRTOF		wcstof
#define STRTOF_L	__wcstof_l
#else
# define STRTOF		strtof
# define STRTOF_L	__strtof_l
#endif

#include "strtod.c"
----

Refactoring to share code between hash modules will ease the changes, 
eg. release the GIL ;-)

fyi - I took care of the unicode data acceptance issue for all hashlib 
related modules in the py3k branch in r69524.

Yes, the hashlib modules have a -lot- of code in common.  Refactoring 
that would be nice but i haven't looked into it.  I at least moved the 
commonly used #define into a new hashlib.h for the above change.