[sni[]
> All I think we're currently missing is an idea of 'what magic methods does an
> object need to provide in order to pretend to be a container, rather than
> just
> an iterable?'
>
> Change dict.keys/values/items to return views which implement that set of
> methods, and all should be good.
That was my intent. I've changed the PEP to better reflect what I'm
trying to do.
In short, a view is really a semantic mechanism, a list of minimal
methods we need to do xyz.
I've heard people going back and forth about views and iters, there
seems to be some confusion, so I want to clarify.
An iter is something that your object *generates* to contain the state
of your current iteration. Notice that a dict has no __next__ method,
but an iter does, this is because the state of your loop is specific to
that for loop and not shared.
Iters are generated, each call to __iter__ creates a new object. Views
are not generated, they are either directly implemented, or returned. I
see .items/.values returning a link to another object that is symbotioc
to a dict, basically the dict but with different method mappings. In
the C code, the structure would be:
dict <--
|
|<- item view
|<- value view
Dict .items and dict .values would basically be references to these
parasitic objects that provide the alternative interfaces. THere isn't
actually a reason for them even to be callable except for backwards
compatability. As a view contains only the state of its host, you don't
need to generate one, only to take a reference.
Now for backwards compatability, I'd like to consider making them
callable, that is calling a dict's item will self-return so that old
code doesn't break.
Somebody mentioned having a __views__ or __flavor_a_view__ method to
implement views. We should, but I don't see the difference between
dict.items()
items_view( dict )
In fact, IMHO the former is more useful ... its the dict object that has
the best idea of what views the dict object can provide.
Personally, I don't like the idea of a __views__ method because it
doesn't seem to make sense, perhaps I'm just unable to wrap my mind
around it, but internal to each object is the knoweledge of what views
make sense. So, what would a __view__ method do? Perhaps return a
catalog of perspectives ( my keys, my items, my values ) and the views
they are associated with ( SetView, Setview, View )?
- Adam DePrince
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
