Status of PEP's?

[James_Althoff at i2.com]

[Timothy Delaney]
> For the record (I've said this before), I like the idea of integers
> being iterable (and I'm not a set theory wonk).

[Alan Daniels]
> That's fine if you like the idea. I don't. The only validations
> I've seen for it are obscure references to set theory, or the vague
> notion that it looks neat since it would make Python read more like
> Haskell (or insert whatever favorite research langugage here). I have
> yet to see any meaningful explanation on how it fixes some gap in
> Python, or improves it other than saving the need to type the word
> "xrange".

The actual PEP has a "rationale" section.  Neither set theory nor Haskell
come into play in the rationale.  If you are happy with xrange when dealing
with the indices of indexed-collections, then you will not be swayed by the
rationale for PEP 276.  Not everyone has thought xrange to be ideal,
though.

> While I'm at it, two problems with it that I haven't yet seen
> addressed:
>
>  1) If you have a class that defines both __int__ and __getitem__
>     methods, and iterate over an instance of it, which method "wins"
>     comes iteration time? The usual, or the "for i in 5" trick?

PEP 276 doesn't propose any tricks.  It suggests adding an iterator to the
int class.  If you define your own class with an instance x, and do "for i
in x" the for-loop will try to get an iterator from your instance x -- just
because that's what the for-loop does. PEP 276 doesn't affect this behavior
in any way.


>     Maybe this is covered in PEP 276. I've read through it once when
>     it was first introduced and didn't see any mention on how this
>     would be handled. I'd read it through again, but it's late and
>     frankly reading it makes my skin crawl.

Don't worry, I have some ointment for you <wink>.  (Seriously though, is
that kind of comment really necessary?  I understand that you strongly
dislike the proposal.  But throwing in zingers isn't very considerate).


> 2) Anyone new to the language will wonder exactly why it is that they
>     can iterate over ints, strings, tuples, lists, dictionaries,
>     files, generators, and indeed, any class instance that implements
>     an iterable interface...
>
>     ...but not floats. Hey, if "for i in 5" means something, then
>     obviously "for i in 5.0" should mean something too, right? That's
>     what a newbie will think, and what good reason answer will anyone
>     be able to give them?

Play with some code and see if you can come up with a meaningful, useful,
practical, and reasonable-to-implement definition for a sequence of numbers
related to a given floating point number x.  I suspect that you will find a
lot of tricky issues.

> As I've come to think of it, the whole point of
> "iterating" is that the programmer is walking through a collection:

Others clearly agree with this perspective.  I think that it is
overly-restrictive to say that the *only* thing that you can iterate is a
collection.

> I can NEVER bring myself to see an integer as a collection,
> not outside of a lecture on number theory, anyway.

There's no requirement to think about number theory or to view integers as
collections here.  All that is suggested is a slightly-less cluttered (than
current) way to iterate the indices of an indexed-collection.  If you are
happy with range/xrange, so be it.

> Sorry to rant, but this is the only idea for Python I've seen
> in a VERY long time, since the 1.5.2 days, where rather than
> capturing my interest and giving me something to contemplate, just
> strikes me as ugly, and stays ugly no matter how long I look at it.

Well then, I guess you'll be giving PEP 276 high marks for "originality"
<wink>.

Jim