Status of PEP's?
James_Althoff at i2.com
James_Althoff at i2.com
Fri Mar 1 23:19:05 CET 2002
> 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
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,
> While I'm at it, two problems with it that I haven't yet seen
> 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
> 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"
More information about the Python-list