Status of PEP's?

[Jeff Hinrichs]

"Carel Fellinger" <cfelling at iae.nl> wrote in message
news:a5pmvd$fic$1 at animus.fel.iae.nl...
> Jeff Hinrichs <jlh at cox.net> wrote:
>
> > What you are asking everyone to agree with is:
> >         5 = [0,1,2,3,4]
>
> No he isn't:)  He explicitly says he doesn't think of sequences at all.
If it walks like a duck and talks like a duck...
  It's a duck.   How can one iterate over something that is not a
sequence/collection?
> ...
> > If you were to restate the above as:
> >        f(5)=[0,1,2,3,4]
> > Then, I believe, that you wouldn't have any problem convincing a large
> > majority that it is possible for f() to produce such an output.  That
being
>
> And this is precisly what he's proposing, f is called iter in his
> case.
But this is already in the language.  It is called range/xrange.  I haven't
seen any argument on why range/xrange is less preferrable to iterable
integers.  I've heard the philosophical debate but not seen how python would
be better for this addition.  If a good, tangible case were made I could be
influenced.
It would have to be a stronger case than:
for i in 5:        is better than              for i in range(5):
  print i                                                print i
I say that it isn't because the first case implies while the second case is
explict.
And it should show how my code would be improved in any of the following
terms,
a) readability
b)robustness
c)minimizing bugs

>He comes from the camp that sees everything as an object, so
> numbers are objects to.  Hence integers know to do things, like
> adding, subtracting, and ... counting!  Three knows how to count from
> zero upto but not including three.  If you accept this, then the
> discussion is not whether integers are sequences, but whether it's
> natural to stretch Python's `for' construct to mean `count' or `over
> its preceding numbers' in case of an integer.
But I don't accept this.  **Not everything is an object.**  An apple is an
object.  A number is an abstact idea already.  You can hold an apple.  You
can not hold a 7.  A number is a property of something else.  It is an
atomic property.  A number does not have ancestors nor children.  Just
because I have 7 apples doesn't mean that at one time I had 6.  Numbers
don't perform operations, you peform operations on operands.
To make a number be able to count and perform operations on itself seems to
me to be an extreme case of the tail wagging the dog.

>Like the `for'
> construct recently got stretched to mean `over all lines' and `over
> its keys' for text-files and dictionaries.  Admitted in those cases it
> still was a clear `iterate over', but the what was debatable.
The reason for this, is that it is natural to view a file/keys as a
collection.  It is not natural to consider a number as a collection of other
numbers.

>
> > said, I would find that the argument favors the use of range/xrange over
the
> > concept of iterable integers.
>
> I'm still concerned how it releates to `programming for everybody',
> as that goal is a sure measure to keep Python lean and simple.
I am not sure whether you are referring to iterable integers or range/xrange
by the above.
> --
> groetjes, carel
-Jeff Hinrichs