Status of PEP's?

[Alan Daniels]

[snippety doo dah, snippety ay...]

"Delaney, Timothy" <tdelaney at avaya.com> wrote in message
news:<mailman.1014938571.8011.python-list at python.org>...
> > The two lines...
> >     for i in 5: print i
> >     for i in 5, 6: print i
> > ...would behave differently under the proposal.
> 
> They behave differently now. One is a syntax error, the other isn't.

Well duh, that's my point. It *should* be an error. "for i in 5" has
no natural meaning, and grafting one onto it just to save having to
type "xrange" would be, in my opinion, a detriment to the language.

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

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

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?

    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.

 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?

> ...an integer will not be an iterator. An integer will be
> iterable...

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

A tuple is a collection, naturally.
So is a list.
A string is, umm, a collection of characters (Cough).
A file is a collection of lines, mostly, if you squint at it right.
A dictionary is a collection of keys, where each key maps to a value.
An class instance can be a collection, as long as it acts like one.

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

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.