This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author christian.heimes
Recipients christian.heimes, gvanrossum, rhettinger
Date 2007-12-10.00:48:22
SpamBayes Score 0.000357902
Marked as misclassified No
Message-id <>
In-reply-to <>
Raymond Hettinger wrote:
> 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.

PyUnicode is the common case for dict keys in py3k. Attributes etc. are
all PyUnicode instances.

> 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.

I wonder how I should store unicode_eq. It's required for dict and set
optimization and I like to keep it static inline. But I can't access
unicode_eq in setobject.c when it is declared as static in dictobject.c.

I could either declare unicode_eq as extern or I could put the method
into a header file which is included by both c files.

> 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.


Date User Action Args
2007-12-10 00:48:22christian.heimessetspambayes_score: 0.000357902 -> 0.000357902
recipients: + christian.heimes, gvanrossum, rhettinger
2007-12-10 00:48:22christian.heimeslinkissue1564 messages
2007-12-10 00:48:22christian.heimescreate