On 3/29/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > Without a direct reason in terms of the language needing a > standardization of an interface, perhaps we just don't need views. If > people want their iterator to have a __len__ method, then fine, they > can add it without breaking anything, just realize it isn't part of > the iterator protocol and thus may limit what objects a function can > accept, but that is there choice.
Good point. I think we need to start from strong use cases. With these, I agree that the view concept is a good implementation technique to consider. But let's not implement views just for the sake of having them - I'm pretty sure that was never Guido's intention. I still think my earlier analysis is important - for loops have no direct access to the iterator/view/whatever, and inline code has access to the original object. So the *only* relevant use cases are those where people are writing functions which take "extended iterator" arguments, where those functions cannot reasonably take either an additional argument which is the original object, or take the original object (an iterable) *instead* of an iterator. The key here is generators - with a generator, there is no "original object". But then again, generators are never going to be anything other than pure iterators, either. So you either allow them or don't, and if you don't, you can't say you take "any iterator". I'm still left wondering whether there are any really good use cases. The itertools module shows how much you can do without needing more than an iterator. Suggestion: Start with a call for use cases, and begin the PEP with nothing more than those. It's not normally what a PEP looks like, but it would probably help to capture things in this case. Paul. PS I also wonder whether adaptation would apply here. Pass the "original object", and the function adapts it to the view it needs. The advantage is that it supports the idea of passing concrete objects round, rather than partial views, while still allowing functions to be specified in terms of a limited interface. The disadvantage is that adaptation is still somewhat in flux, and it's possibly overkill for this issue. _______________________________________________ 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
