On Thu, Jun 12, 2008 at 2:32 AM, Terry Reedy <[EMAIL PROTECTED]> wrote: > > "Scott Dial" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > || If non-string keys are not allowed in __dict__, then the AddOns library > | should be changed to add another dict to the object of interest to track > | these AddOn instances. > > There are three possibilities with respect to __dict__ and non-string keys. > 1. All implementations must reject such. > 2. Each implementation decides for itself. > 3. All implementations must allow such. > > Current, CPython does not reject, eliminating 1). Since, as I understand > it, at least 1 other implementation does reject, 3) is also eliminated > until Guido decrees otherwise and such implementation(s) change. This > leaves 2) as the de facto situation, but this could be made clearer in the > docs: "The result of trying to add non-string keys to any __dict__ > attribute is implementation defined." This means that portable Python code > must act as if 1) were the case. > > The Data Model chapter of the Reference Manual lists .__dict__ as a special > attribute of callables, modules, classes, and instances. It describes > __dict__ as a "namespace dictionary" or "implementation of the namespace" > thereof. Since namespaces map names (or possibly non-name strings) to > objects, this to me implies that an implementation is and should not be > required to allow non-strings in __dict__. > > The same chapter has more than one sentence saying something like "o.x is > equivalent to o.__dict__['x']". While one could read this as prohibiting > o.__dict__[non_string], one could also read it as being silent, neither > allowing nor prohibiting. > > The builtin interface functions setattr, hasattr, getattr all require > strings for accessing the underlying __dict__. Since they could have been > defined otherwise, to accept any object as an attribute 'name' (key), this > again implies (to me) that __dict__s are only intended and only required to > have string keys. Hence, I was initially surprised that 1) above was not > true. So I might add something stronger to the docs, something like "The > special __dict__ attributes are only intended to hold string keys. If an > implementation allows other keys, that is only an current accidental > side-effect of considerations of parsimony and efficiency." > > Contrariwise, if 3) were mandated, then I would think that the xxxattr > functions should be changed. > > Terry Jan Reedy > > > > _______________________________________________ > 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/fijall%40gmail.com >
This is completely irrelevant. This post is not about assigning non-string stuff to __dict__ of class which works completely fine. It's about abusing locals, which are not even given that they'll modify this dict. _______________________________________________ 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
