[Python-Dev] Should vars() return modifiable dict?

[Terry Reedy]

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