"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| At 08:32 PM 6/11/2008 -0400, Terry Reedy wrote:
| >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.
|
| As it happens, most objects' __dict__ slots are settable by default,
| and *require* that you set it to a dict or subclass thereof.  This
| seems (to me) to imply that a standard dictionary (i.e. one
| supporting keys of any type) is required.  (In the sense that a dict
| subclass which rejects non-strings would be violating the Liskov 
principle.)

Is this requirement a documented Python requirement (not that I found), an 
undocumented Python requirement, or a CPython-specific requirement (that 
other implementations may freely ignore)?

I don't have much opinion on what the rules for __dict__ attributes should 
be, just that whatever they are  should be documented.  This include 
implementation-defined aspects.  This will help both implementors and users 
who wish to write Python code rather that CPython code.

If there is a consensus and BDFL pronouncement, I will make or help review 
suggested doc changes.

tjr



_______________________________________________
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

Reply via email to