At 01:34 PM 6/12/2008 +0200, Carl Friedrich Bolz wrote: >Phillip J. Eby wrote: > > As it happens, most objects' __dict__ slots are settable by default, and > > *require* that you set it to a dict or subclass thereof. > >This is wrong for types: Which is why I said "most" - to exclude types, and objects that don't have a __dict__ slot to begin with. >I think there are good arguments for not allowing strings keys in type >dicts, or at least leaving it up to the implementation. That may well be, but there is nothing in Python's spec that I'm aware of that *forbids* it. For example the type() constructor doc doesn't say anything about using string-only keys in the class dictionary. >Using non-string >keys in type dicts is relatively awkward and allowing them makes many >interesting optimizations (like method caches) a _lot_ harder to get right. Really? Why? Having non-string dict keys is NOT the same thing as having non-string attribute names, so attribute name lookups should be unaffected. (Attribute names *are* required to be strings, and -- as far as I know -- always have been.)
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