[Python-3000] Iterators for dict keys, values, and items == annoying :)

Brett Cannon brett at python.org
Thu Mar 30 02:31:04 CEST 2006


On 3/29/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Brett Cannon wrote:
>
> > Basically a simple
> > set interface where we could have a __container__/__view__/__set__
> > whatever method to call to get a view of the data structure.
> > Basically a read-only (with a possible delete possibility) mapping
> > interface.
>
> If there's an obvious default meaning for the basic access
> methods like __contains__ and __len__, there's no need for
> a view to provide these -- the original object can (and
> should) just implement them itself.
>
> Views only come into play when there is more than one
> possible view of an object (e.g. dict has keys, items,
> values). Then the details are completely type-specific.
>
> There might be room for a general immutable view object
> that doesn't allow any changes, but that could be
> provided as a generic wrapper that doesn't need to know
> anything about the base object or vice versa.
>

Maybe.  If people really want to have a frozen set that contains the
keys or values of a dict those could be added to the dict type.

> > Without a direct reason in terms of the language needing a
> > standardization of an interface, perhaps we just don't need
>  > views.
>
> On the contrary, views are a very useful idea, *as a
> design pattern*. What we *don't* need in Python, as far
> as I can see, is any formalised protocols or interfaces
> for views, because there's nothing that can be said about
> them in general.
>
> Thinking that "having views" means "having a formally
> defined interface for views" is a mindset that comes
> from B&D languages like Java. It doesn't apply to
> Python at all.
>

Right.  I am just talking about views not being needed in terms of
being formalized for the language.  Just like how the mapping protocol
is there, but not formalized.  I am not arguing about the usefulness
of views in terms of a concept.

-Brett


More information about the Python-3000 mailing list