PEP 276 Simple Iterator for ints

[Ken Seehof]

> Ken Seehof wrote:
> >Hey, what ever happened to the int[:10] iterator idea?
> >
> >>>> for i in int[2:10:2]: print i,
> >2 4 6 8
>
> Nothing actually *happened* to it. ;-)
>
> It needs a PEP (or needs to be added to an existing PEP).
>
> Among the issues that the PEP should probably address are:
>
> - Does int[] return a list or an iterator?  (Or an iterator that
implements
> some or all of the sequence protocol?)
>
> A list would be useful in many cases and would be a bit more consistent in
> the sense that slicing applied to current builtins returns actualized
> sequences not iterators.
>
> But iterators are more useful for for-loops (because you don't have worry
> about generating large sequences unnecessarily).
>
> So both are useful.  Do we need two mechanisms?  What would be the
proposal
> for that?

I think iterator.

> - Does int[] do anything more than act as a new spelling for the "range"
> function?  (Or "xrange", depending on the answer to the issue above).

Yeah, I suppose it is.  But then 'print' is just another spelling for
sys.stdout.write.  Sometimes a new spelling is worthwhile if an idiom is
common enough, as long as we don't get too
perlish^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hoverdo it.

Actually, my main motivation in bringing the slice idea up again is to
replace PEP 276 which I don't like because making an integer behave like a
sequence is just weird, and maybe even a bit perlish^H^H^H^H^H^H^Hobscure.
So I think my current attitude is something like this:

1. Integer slicing is better than iter(n), and accomplishes the same
objectives.
2. Integer slicing is just a different spelling for xrange.  So don't
bother.
3. Therefore, might as well just reject 276.
4. But wait, xrange and range are really ugly in for loops.
5. So let's do integer slicing after all.

> - Issues from PEP 204 "Range Literals".  PEP 204 proposed using slice
> syntax to create lists of integers.  That PEP has been rejected.  It
> included some issues such as: how do you handle [:] which is valid slicing
> syntax but contains no end value?  Because the "int[]" proposal is less
> drastic than PEP 204 -- calling for the implemetation of __getslice__ as a
> class method on types.IntType rather than new syntax -- most of the issues
> in PEP 204 are probably not a big deal.  But the PEP author should
probably
> give them consideration.

I agree.  PEP 204 would have been nifty, but I have to agree with it's
rejection mostly because the benifits don't seem to be worth the problems
associated with adding new core syntax.

The `end' argument issue goes away if the slice returns an iterator, so
int[:] returns the sequence of natural numbers [0, 1, 2, ...], which would
be a useful idiom as an infinite for loop:

.   for i in int[:]:
.        print i
.        do_something(i)
.        if done(): break

The syntax issues of 204 (mixing with list literals and list comprehensions)
don't apply since no new syntax is added.

Accepting non-integer arguments is unambiguous: return an integer sequence
sliced according to normal slicing rules (e.g. after numeric unification,
int[:2.0] would yield iter([0,1])).  As I mentioned before, float[:3.0] ==
[0.0, 1.0, 2.0], where slicing is implemented separately for the float
class.

> Finally, it should be noted that PEP 276 -- adding an iterator to
> types.IntType -- doesn't preclude implementing __getslice__ as a class
> method of types.IntType as suggested above.

True, but having both would seem to be redundant, since you would not need
both solutions which would be redundant.  Hence I am suggesting int slicing
as an alternative to PEP 276 (did I say that already? :-)

BTW, as a reminder, __getslice__ is depricated, so we are really talking
about __getitem__(slice), which amounts to the same thing.

- Ken