"Guido van Rossum" <guido at python.org> wrote in message news:ca471dc20712012052g662a1901hfa571d72e057262f at mail.gmail.com... | On Dec 1, 2007 7:09 PM, Neil Toronto <ntoronto at cs.byu.edu> wrote: | > Are there any use-cases for allowing namespace dicts (such as globals, | > builtins and classes) to have non-string keys? I'm asking because I'm | > planning on accelerating method lookups next, and the possibility of a | > key compare changing the underlying dict could be a major pain. (It was | > a minor pain for globals.) | | Since this has always worked, I suspect there are probably some | packages that depend on this. My impression from a decade of reading c.l.p. is that most people posting there regard the possibility, when bypassing the normal identifier access mechanisms, of putting non-identifiers, let alone non-string keys into namespace dicts, as 1. Surprising (because they assumed a string- or name-only dict was used). or 2. A side effect (implementation dependent) of Python economizing on types. (But with the result of spurring optimization of dicts, which in turn reduced the motivation for a specialized type [until now].) In any case, it seemed pretty useless, since naming and using a dict was/is both easier and safer (more future proof). But there may have been a person or two who liked having semi-hidden variables or attributes. |We could deprecate this however in 2.6 | and forbid it in 3.0; it's easy enough to switch to string keys, | either using a unique prefix or even non-identifier characters like | '.' or '$'. Or use a separate, unrestricted, regular dict. +1 tjr
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