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

[Guido van Rossum]

[redirecting to the py3k list where this belongs]

On 1/16/07, Tim Delaney <tcdelaney at optusnet.com.au> 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/)