PEP 284, Integer for-loops

[James_Althoff at i2.com]

Appreciation to David for writing the PEP -- doing so takes time, energy,
and commitment.

Here are some comments:

I think it would be good to add a sentence or two to the "issues" part of
the PEP that notes the discussion that took place in prior posts about the
limitation of the proposal in terms of needing to write a for-loop or list
comprehension *twice* in cases where one wants to be able to handle both
increasing and decreasing values in an interval.  I think this should be
noted as an issue or known limitation -- there are some words in the PEP
that position this more as a feature -- because it is *not* a limitation of
the current range and xrange functions.

I would appreciate a sentence or two in the "issues" section that notes
(explicitly) that shortcuts such as
    "for i < len(myseq)"
will not be supported.  I think this is relevant because I agree with Bjorn
Pettersen that not everyone will consider
    "for 0 <= index < len(myseq):"
to be a significant improvement over current methods for the common case of
processing the indices of a sequence.

I think the section that talks about loop semantics
    "one way of interpreting the existing Python
    for-loops:

        for item in list

    iterates over exactly those values of item that cause the
    expression

        item in list

    to be true."
should be removed or modified.  Python for-loops don't currently enforce
that stated property as this simple example shows:
>>>
>>> class spam:
...   def __init__(self):
...     self.items = [1,2,3]
...   def __iter__(self):
...     for item in self.items: yield item
...     raise StopIteration
...   def __contains__(self,x):
...     return 0
...
>>> spm = spam()
>>> 1 in spm
0
>>> for x in spm: print x
...
1
2
3
>>>
You could state the above as a property of various builtin Python objects,
perhaps.  But clearly, it is not an inherent property of (nor the defining
semantics for) for-loops.

I agree with other posters who stated concerns about the limitations of the
proposal given that the proposal is heavyweight -- in the sense of
requiring syntax changes -- where the limitations include as others have
noted:
  - arbitrary step values not supported (already noted in the PEP),
  - no first-class interval objects (already noted in the PEP).

The PEP is worded in such a way that the syntax change appears to be work
*only* for certain existing builtin Python object types: "int" and "long"
specifically.  Is this really the intention?  Will the syntax not work for
instances of a subclass of int (now possible in Python 2.2), for example?
Or other classes that support some reasonable protocol?  If so, I think
some words in the "issues" section are appropriate to highlight this
limitation.  I believe it is a pretty big limitation to have a major, new
syntactic construct that can *only* support instances of two classes (int
and long).

Or is it the intention that the construct is *not* limited strictly to the
Python builtin classes "int" and "long"?  Will it work for any class that
defines __lt__, __lg__, __gt__, __ge__, __add__, and __radd__ methods, for
example?  And if so, the specification part of the PEP should explain how
this would work.  For example, will __add__ be called with arg 1 or -1
(builtin integer objects)?  So must __add__ be able to accept 1 and -1 as
the arg to __add__ as part of the specification?  Or does there need to be
a "successor" method as was suggested in another post?

A lot of thought and work has been put into the syntax part of the
proposal.  I think some more thought and work might be required on the
semantics.

Jim