[Python-Dev] dict.items as attributes [Was: The bytes type]
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
> 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
> 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.
More information about the Python-Dev