[redirecting to the py3k list where this belongs] On 1/16/07, Tim Delaney <[EMAIL PROTECTED]> wrote: > 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.
Indeed, the views won't have independent state (apart from the pointer to the dict). But independent state is not the only reason to make something a method instead of an attribute. I find it hard to explain, but my gut feeling is that using an attribute instead of a method would be a mistake here. In the past I've paid deerly for ignoring my gut feelings (about language design as well as about other things) so I'd rather wait until a rational explanation comes to me instead of changing my mind now. I'll gives a few half-reasons that might help: - We had the same argument (attribute or method) over hash(), and decided against change (see PEP 3099). - In terms of API design, choosing methods is actually *more* compatible with Python 2.x than choosing attributes. - I looked at the pros and cons of caching the view objects in the dict as opposed to creating a new one on each use, and decided that the extra slots needed in every dict to hold three different views weren't worth the minor savings that could be had by the caching; caching could even be a net loss since each view would end up living as long as the underlying dict once created. Any more complicated approach (weak refs, a separately malloc'ed appendage) would cause more complexity than it's worth, since the views are super-simple objects (in terms of their state) anyway. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
