[Python-Dev] dict.items as attributes [Was: The bytes type] (original) (raw)

Tim Delaney tcdelaney at optusnet.com.au
Tue Jan 16 18:59:15 CET 2007

Phillip J. Eby wrote:

To be honest, the items() and keys() thing personally baffles me. If they're supposed to be views on the underlying dictionary, wouldn't it make more sense for them to be attributes instead of methods? I.e. dict.items and dict.keys. Then, we could provide that feature in 2.6, and drop the availability of the callable forms in 3.0.

Then you could write code like: for k,v in somedict.items: ... And have it work in 2.6 and 3.0. Meanwhile, .items() would still return a list in 2.6 (but be warnable about with a -3 switch), but go away entirely in 3.0.

I think this comes down to whether or not the views returned have any independent state. There's something that tells me that attributes (even properties) should not return different objects with independent state - working on two views obtained from the same dictionary property should either work identically to working on one view bound to two names, or they should not be obtained from a property.

But unless I'm mistaken, everything done to a view would pass through to the dict, or result in another object that has independent state (e.g. iter()) so the effect of working on two views of a dict would be identical to working on two names to the same view. The only case I can think of for which we might want to hold state in the view is for detecting concurrent modification - I know that iterators should throw exceptions in this case, but I can't remember what (if anything) was decided for views.

Tim Delaney

More information about the Python-Dev mailing list