I'll try to be more explicit; if Josiah and I are talking past each other, than the explanation was clearly not yet mature.
(In http://mail.python.org/pipermail/python-dev/2005-October/057251.html) Eyal Lotem suggested: > Name: Attribute access for all namespaces ... > global x ; x = 1 > Replaced by: > module.x = 1 I responded: > Attribute access as an option would be nice, but might be slower. > Also note that one common use for a __dict__ is that you don't > know what keys are available; meeting this use case with > attribute access would require some extra machinery, such as > an iterator over attributes. Josiah Carlson responded (http://mail.python.org/pipermail/python-dev/2005-October/057451.html) > This particular use case is easily handled. Put the following > once at the top of the module... > module = __import__(__name__) > Then one can access (though perhaps not quickly) the module-level > variables for that module. To access attributes, it is a quick scan > through module.__dict__, dir(), or vars(). My understanding of the request was that all namespaces -- including those returned by globals() and locals() -- should be used with attribute access *instead* of __dict__ access. module.x is certainly nicer than module.__dict__['x'] Even with globals() and locals(), I usually *wish* I could use attribute access, to avoid creating a string when what I really want is a name. The catch is that sometimes I don't know the names in advance, and have to iterate over the dict -- as you suggested. That works fine today; my question is what to do instead if __dict__ is unavailable. Note that vars(obj) itself conceptually returns a NameSpace rather than a dict, so that isn't the answer. My inclination is to add an __iterattr__ that returns (attribute name, attribute value) pairs, and to make this the default iterator for NameSpace objects. Whether the good of (1) not needing to mess with __dict__, and (2) not needing to pretend that strings are names is enough to justify an extra magic method ... I'm not as sure. -jJ _______________________________________________ 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
