PEP 276 Simple Iterator for ints

[William Tanksley]

On Tue, 13 Nov 2001 17:00:29 -0800, James_Althoff at i2.com wrote:
>William Tanksley  wrote:
>>On Tue, 13 Nov 2001 13:31:21 -0800, James_Althoff at i2.com wrote:

>>I'm not sure I like this aspect anyhow.  "5" just doesn't seem similar to
>>"0,1,2,3,4".  A single integer isn't a range.

>>>    - Possible ambiguity
>>>          for i in 10: print i
>>>      might be mistaken for
>>>           for i in (10,): print i
>>>      Response: The predicted ambiguity was not readily apparent to
>>>      several of the posters.

>>You'll have to do better than that.  This is the same problem as issue 1
>>(immediately above).

An important point.  "for i in 10,:" is an enormously different thing
under this proposal that "for i in 10:"

>>>    - It would be better to reuse the slicing literal syntax attached
>>>      to the int class, e.g., int[0:10]
>>No.  I said that would be better to implement __getslice__ as a
>>sequence-returning class method of the int class, e.g. int[0:10].  I'm not
>>interested in proposing syntax changes.

>Got it. But can __getslice__ be changed from an instance method to a class
>method for types.IntType and still work without special casing?  I don't
>know about this.

Chris posted a quick and dirty hack which works, or appears to work.  At
any rate, it demonstrates the concept.

>In any case, presumably the returned sequence would be auto-converted to a
>lightweight iterator in the for-loop (as lists are).  Seems that PEP 276
>has the advantage of directly creating an iterator without the need of
>first creating a sequence object.

My intention was to have this __getslice__ return a generator, not a
tuple.  It's clear that I'm proposing occasionally infinite slices, so
generating a sequence would be phenominally foolish :-).  I would also
like to have the returned object implement __getitem__, since it's
relatively easy, but that's a different topic.

>>I claim that it's better because your method because your method doesn't
>>_look_ like a range and doesn't act like other Python usages.  In essence,
>>it makes Python integers behave differently in scalar context versus array
>>context -- and we can't have people comparing us to that OTHER P***
>>language <0.4 wink>.

Python already has one expression which behaves differently in a loop
context: "in".

>However, I'm still unclear on the notion of __getslice__ being sometimes
>an instance method and sometimes a class method.  The code generated from
>the slicing syntax would have to try to call it both ways or something, I
>guess?

I don't see why -- you just call the __getslice__ method of the object
you're thrown at.  Aren't builtin types also objects?

>Agree with you that a PEP would be good. ;-)

Here's a place I wish people would stop agreeing with me.  :-)

>Jim

-- 
-William "Billy" Tanksley