Raymond Hettinger added the comment: 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. __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1564> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
