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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
