On Thu, Jun 12, 2008 at 2:56 PM, Carl Friedrich Bolz <cfbolz at gmx.de> 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)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4