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

Terry Reedy tjreedy at udel.edu
Fri Oct 5 20:32:58 CEST 2012

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

More information about the Python-Dev mailing list