On Tue, Nov 28, 2017 at 10:49:45AM +1300, Greg Ewing wrote:
C Anthony Risinger wrote:
* Perhaps existence of `__len__` should influence unpacking? There is a semantic difference (and typically a visual one too) between 1-to-1 matching a fixed-width sequence/container on the RHS to identifiers on the LHS, even if they look similar (ie. "if RHS has a length make it fit, otherwise don't").
-1. There's a convention that an iterator can implement __len__ to provide a hint about the number of items it will return (useful for preallocating space, etc.)
I think you mean __length_hint__ for giving a hint. If an iterator supported __len__ itself, I'd expect it to be exact, not a hint. I'm not sure that its a strong convention, but we certainly could create custom iterators that supported len(). https://www.python.org/dev/peps/pep-0424/
While I like the original proposal, adding basic slice support to iterables is also a nice idea.
It's not as nice as it seems. You're asking for __getitem__ to be made part of the iterator protocol, which would be a huge change affecting all existing iterators.
There are ways around that. As I said earlier, I'm not going to champion this idea, but for the sake of brainstorming, the interpreter could implement obj[slice] as: if obj has __getitem__: call obj.__getitem__(slice) elif iter(obj) is obj: call itertools.islice(obj, slice) else: raise TypeError or similar. Its not literally necessary to require iterators themselves to support a __getitem__ method in order to add slicing to the iterator protocol. (Similar to the way bool() falls back on testing for non-zero length in the event that __bool__ doesn't exist, or != falls back on calling and NOT'ing __eq__ if __ne__ doesn't exist.) So I think this is solvable if it needs to be solved. -- Steve