Which is the common case in Py3k, to have strings or unicode?  By 
trying to catch both, you slow down the optimization.  Also, the 
new "hash_fast" introduces function call overhead in previously in-
lined code.

My preference is to knock-out the optimization or leave in the way it 
is.  Remember, strings already cache their hash codes and that 
optimization is being short-circuited here.

For sets, I prefer the code to be left as it is.  For dicts, whatever 
you do, don't slow-down the common case of regular attribute lookup.  
This is some of the most time critical code in the language.  Trying to 
generalize the optimization, make actually make it slower.

If unicode strings are the norm and an not PyString_Objects, then 
switch to that one, but I don't think you should try to do both.