[Python-Dev] dict.items as attributes [Was: The bytes type]

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