PEP 276 Simple Iterator for ints

[James_Althoff at i2.com]

William Tanksley  wrote:
>On Tue, 13 Nov 2001 13:31:21 -0800, James_Althoff at i2.com wrote:
>>PEP: 276
>>Title: Simple Iterator for ints
>
>It's good to see someone doing useful work here.  PEPs are cool.

Thanks!

>
>>Issues:
>>    Based on some preliminary discussion on the Python interest
>>    mailing list, the following concerns have been voiced:
>>    - Is it obvious that iter(5) maps to the sequence 0,1,2,3,4?
>>      Response: Given, as noted above, that Python has a strong
>>      convention for indexing sequences starting at 0 and stopping at
>>      (inclusively) the index whose value is one less than the length
>>      of the sequence, it is argued that the proposed sequence is
>>      reasonably intuitive to a Python programmer while being useful
>>      and practical.
>
>Strike the part about intuition.  Perhaps "consistent" would be strong
>enough.

Reasonable consistency probably is the key point.

>
>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).
>
>>    - It would be better to reuse the ellipsis literal syntax (...)
>>      Response: Shares disadvantages of other proposals that require
>>      changes to the syntax.  Needs more design to determine how it
>>      would handle the general case of start,stop,step,
>>      open/closed/half-closed intervals, etc.  Needs a PEP.
>
>The last sentance is the only one that matters here.  However, I'm
>curious: what do you mean "reuse"?  I've never seen an "ellipsis literal"
>in Python.  Reading through the Python documentation, I see an ellipsis
>notation for extended slicing, but I'm in the dark as to what it means.
>(I can guess, but I'd rather see it in print.)  I've never seen it in
>Python code, and the documentation doesn't seem to mention it.

There are some concrete examples on page 36 of David Beazley's
"Python Essential Reference", Second Edition.

>
>>    - 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.

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.

>
>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>.
>
>>      Response: Same as previous response.  In addition, design
>>      consideration needs to be given to what it would mean if one
>>      uses slicing syntax after some arbitrary class other than class
>>      int.  Needs a PEP.
>
>Last sentance is still the most important one.  The second sentance is
>nonsense; I don't have to define all possible class reactions to slicing
>simply because I'm defining one!  This is equivalent to someone saying
>that your PEP is bad because you don't define iter() for all classes.

Yes, I misunderstood the suggestion.  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?
Agree with you that a PEP would be good. ;-)

>
>I do, however, fail to define start, stop, and step behavior.  For this
>reason I would propose that the PEP someone else writes for this suggest
>'range' behavior, and require a start.
>

Thanks for your comments and clarifications.

Jim