On Thu, Jun 12, 2008 at 2:56 PM, Carl Friedrich Bolz <[EMAIL PROTECTED]> wrote: > Of course attribute name lookups are affected, because you can have a > non-string key that has a __hash__ and __eq__ method to make it look > sufficiently like a string to the dict. Then the attribute lookup needs > to take these into account. This makes a method cache implementation > much more complex, because suddenly arbitrary user code can run during > the lookup and your classes (and thus your method caches) can change > under your feed during the lookup. In this situation getting the corner > cases right is very hard.
I fully agree with this assessment: the theoretical possibilities make attribute handling very hairy. Note that besides non-strings, also user-defined subclasses of string can have their own hash/eq logic. If namespace keys and attributes could be locked down to only be regular strings, not of another type and not a string subclass instance, then implementing attributes becomes a lot less hairy, and optimizations much more straightforward. - Willem (CLPython) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com