Recap: PEP 276 Simple Iterator for ints

[James_Althoff at i2.com]

William "Billy" Tanksley wrote:
>It isn't even a tradeoff.
>
>You can provide both __getitem__ and __iter__, and you're set.  Providing
>__getitem__ doesn't mean you're a list or tuple; it just means you're a
>sequence.  If you do that the way range() has in the past, you're an
>idiot.  There's absolutely no reason to store all the integers in a range
>which you could instead store start,stop,and step, and generate them as
>needed.

I don't see it as being quite that clear cut.  Take the proposed
Haskell-esque syntax, for example.  If one were to see:

list1 = [0, 1, 2, 3, 4]
list2 = [1, 2 .. 5]

it might be surprising that list1 is an actual list while list2 is a
minimalist sequence.  Since list1 is a real list, one can append to it,
remove from it, replace items in it, slice it, etc.  If list2 is a
minimalist sequence as suggested, then such operations are not defined --
unless even move magic methods are implemented, which seems to be the
*opposite* direction of PEP 260 "Simplify xrange()" (which is done and
implemented).  Like the new xrange, the proposed minimalist sequence might
be designed to "have one idiomatic use", namely, as part of a for-loop.
And perhaps one might propose even that said syntax is *invalid* except in
a for-loop (or in conjunction with "in", say).  But again, this might
surprise users who might see the new Haskell-esque syntax as a nice
extension of the current *list* literal syntax.

Maybe this is ok.  But it still seems to me that there are design tradeoffs
that need to be addressed.

Jim