[Python-Dev] Non-string keys in namespace dicts
tjreedy at udel.edu
Sun Dec 2 07:02:17 CET 2007
"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).
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.
More information about the Python-Dev