On 10/5/2012 9:01 AM, Larry Hastings wrote:
On 10/05/2012 01:59 PM, Devin Jeanpierre wrote:
I've never understood why locals() returned a mutable dictionary
either, except that Python has no immutable dictionary type.
Ah, but these days it has types.MappingProxyType which provides a
read-only wrapper around another mapping type. Perhaps that should be
employed here.
I would like to put this particular tracker issue in a larger context.
I believe that the issue of expanding the meaning of vars() intersects
with the issue of changing the return type of stat and other functions
from a tuple or elaborated tuple to a read-only attribute namespace
object (as I believe Larry and some others wish to do). I understand the
proposal to be to change to something like a named tuple, with dotted
name access to attributes, but without all the tuple behaviors.
The are two major behaviors of tuple to be considered. One is
indexibility. That, I agree, can go. The other is iterability, which
also means introspect-ability. That, I would argue, should not go.
However, one might want to iterate or introspect names, values, or
pairs. We already have a way to do that -- dicts.
So I propose that the meaning of vars(ob), where ob is an object with
attributes, should be expanded from 'return ob.__dict__, if there is
one' to 'return a name-attribute dict for ob (which will be ob.__dict__
when there is one)'. I believe this is in line with the original intent
of vars(), given that all attribute objects once had a __dict__. (I
could be mistaken here, but my memory of 1.4 on this is a bit fuzzy.)
The addition of __slots__ broke that, but it was not the only one.
Giving a meaning to vars(slotted-object) is a partial step in fixing the
break, but only a partial step.
One way to expand the meaning of vars is to update it as necessary when
new internal types or mechanisms are added. This is the proposal in the
tracker. But this is contrary to the principle of information
localization and using __special__ names to access type-specific behavior.
An alternative to teaching vars about various categories and classes of
objects would be to give slotted objects, etcetera, a __dict__ property.
Its __get__ could return a dict_proxy or whatever. This would be a
better place to localize knowledge of how to get the name-attribute
mapping. Then vars() would work on such objects as it currently is,
without change. This is similar to how iter() and next() work with new
classes -- the classes provide the necessary special method. A solution
the to problem of an attribute object not having a __dict__ for vars()
to return is to give it one.
Coming back to my starting point, if read-only attribute objects have a
__dict__ property, they could be introspected and indirectly iterated
in three different ways, without having __iter__ and __next__.
--
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/archive%40mail-archive.com
