PEP 276 (was Re: Status of PEP's?)

[James_Althoff at i2.com]

[Carel Fellinger]
> you being such a heavy weight that I fear
> Guido might be lured into thinking this to be a good idea
> that I felt compelled to react in public.

Well, thanks (I think <wink>), but I can assure you that I hold no special
brownie points and have zero ability to "lure" Guido (or anyone on the
Python team) into anything.  So, no need to lose any sleep over that one.
(On the other hand, if anyone knows *how* to "lure" any of them, be sure to
let me know <wink>).


[Samuele Pedroni offers this perspective sans endorsement <wink>]
> in mathematics it is not uncommon to
> identify the natural numbers with the set
> of their predecessors
>
> 0 = {}
> 1 = {0} = {{}}
> 2 = {0, 1}  {{},{{}}}
> etc

[Carel Fellinger]
> Not only newbie unfriedly, you need a firm grasp of modern set
> based number theory to appreciate it, it seems.

As fond as we all surely are of the neat mathematical underpinnings
suggested here and before, I believe that most programmers -- regardless of
skill level (and pedigree in the field of mathematics) -- would be able to
understand -- and certainly easily remember the second time -- that
iterating on n means taking each of 0,1,2, ..., n-1 in turn; this without
having to think about -- much less have "a firm grasp of" -- number theory
(modern, set-based, or otherwise <wink>).  At least if one has enough
background to understand "iteration" to begin with.

Let's try that again.

Q: What does it mean to iterate a number n?

A: Take each of 0,1,2, ..., n-1 in turn.

Q: When would I want to do that?

A: When you need the indices of an indexed-collection, for example.

(No set theory needed <wink>).

I certainly acknowledge the feelings of those who don't like the suggested
idiom.  At the same time, claims of its alleged *great difficulty* seem
overblown.


[Carel Fellinger]
> So please explain why you think it natural to loop over a number.

The "rational" section of PEP 276 talks about iterating through the indices
of an indexed collection.  These, as we know, are related to the length (an
integer) of the indexed collection.


[Carel Fellinger]
> here in your PEP you make it look like some minority
> of nitwits objected

I don't remember writing anything about nitwits.  But that does remind me
of the joke about "when failing to find a needed wit, they substituted two
half-wits, instead".  Seriously though, I don't recall and didn't intend
any insult to those who don't like PEP 276's suggestion of an iterator for
integers.  Please feel free to point out the actual text that you find
offensive.


[Aahz Maruch]
> My primary complaint about the PEP is that the following idiom is
> awkward, ugly, and prone to misunderstanding:
>
>   if i in 5:

I will note this.

However given that current Python seems able to do type-checking on strings
used with "in" as in, for example:

>>> 1 in 'spam'
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'in <string>' requires character as left operand
>>>

it's not obvious (to me, anyway) why the same (throwing a TypeError, that
is) could not be done for ints assuming one believes that "i in 5" is so
bad.   On the other hand, as noted by Bjorn Pettersen, "if i in
len(mylist):" seems like a pretty straightforward and handy thing to write.
I would use it were it available.  And I don't think it would confuse any
of the developers I work with. YMMV


[Remco Gerlich]
> Compare:
>
> for i in 6: print i
> for i in 6,7: print i
> for i in 6,7,8: print i
>
> You wouldn't think the first line does something different, would you?

[Emile van Sebille]
> Is that really any different from what we have now:
>
> for i in "Spam": print i
> for i in "Spam","and": print i
> for i in "Spam","and", "Eggs": print i

[Andy Gimblett]
> Yes, it really is.  "Spam" is a sequence, whereas 6 isn't.

I agree with Emile on this one.

>>> for s in 'spam': print s
...
s
p
a
m
>>> for s in 'spam','eggs': print s
...
spam
eggs
>>>

Two different results.  One needs to understand how and why.  Sometimes one
wants to treat a string as a unit, other times as a sequence.  It's useful
and convenient to be able to do both.


[Courageous]
> for i in [0:len(mylist):1]:

[Bjorn Pettersen]
> And exactly this notation has been rejected in PEP 204 --
> basically because it's butt-ugly in a Perl'ish sort of way
> Besides, this goes under the section of solving the "interval"
> problem which PEP 276 *explicitly* says it is not doing (and which
> I personally don't find very compelling, especially if PEP 276 is
> adopted).

I agree with Bjorn.  A lot of alternatives for full-blown intervals were
proposed during previous discussions of PEP 276.  Many of them require new
syntax.  Much of such new syntax, though logical and nice in theory, ends
up looking pretty cluttered when used in common examples.  PEP 276 attempts
to reduce clutter for a common case with minimal change to Python (no new
syntax at all).  In any event, proponents of alternatives should take the
time to write a PEP.


[David Eppstein]
> Maybe it's as natural as Perl's ability to concatenate numbers?

I don't appreciate your sarcasm.  Maybe others do.


Jim