Status of PEP's?

[James_Althoff at i2.com]

[Fernando Pérez]
> When 'for i in 5' becomes valid, what we are saying is, the object '5'
> knows how to count.

*You* can say that if you like; but PEP 276 doesn't say that <wink>.  It
just proposes an iterator for class int whereby said iterator generates the
-- well, I was about to use the word "natural", but I think I'll skip that
<wink> -- "useful" sequence 0,1,...,n-1.

> Apparently this is ok, but I see problems: '5' is an integer,
> but there are also negative numbers in the integers. So how do we
> interpret 'for i in -3'?

PEP 276 (currently) proposes that "for i in -3" acts just like "for i in
xrange(-3)" currently does.  Carel Fellinger suggests that it might be
quite handy to have it act just like "for i in xrange(-1,-3-1,-1)",
instead. And Emile van Sebille, with only a semi-smiley attached (a smiley
semi-attached?) suggests that the reverse ordering would be better, should
the empty set not be returned in such a case.

> While one can argue that 0..4 is a 'natural' way to count for
> positive integers, the same argument becomes difficult to make
> for negative numbers. And by the way, as far as counting goes one
> could argue that 1..5 is even more natural, as it truly spans the
> set of the natural numbers of which 5 is a member, as opposed to

Bet you didn't think *that* was going to be so controversial <wink>.

> the less 'standard' set of the 'non-negative integers less than 5'.
> But that's a minor nit-pick.

Easy answer: forget about "counting" and consider this interesting excerpt
from range.__doc__
    "For example, range(4) returns [0, 1, 2, 3].
    The end point is omitted!
    These are exactly the valid indices for a list of 4 elements."
Take special note of the last sentence <wink>.

> The problem in my view is that when something is an object, its
> methods should do something which is reasonably natural and well defined
> for _all_ instances of a class. So when we ask the integers to have a
> counting method (via an iterator), I would want to have that counter
> behave sensibly for _any_ integer. And unfortunately, there's just no way
> to make such a definition IMHO.

Why is there "just no way to make such a definition"?

Please consider the following:
    for integer n, iter(n) produces the same values as iter(xrange(n))

> So this ends up introducing lots of context-sensitivity and
> special-casing (things work _this_ way for non-negative integers,
> which is not too clean but commonly useufl, and do _that_ for negative
> ones because someone thought it would be a usefu default...) Down that
> road lies Perl, and it seems to break very harshly the 'explicit is
better
> than explicit' principle of Python design which I feel has served the
> language so well thus far.

That seems a lot more complicated than PEP 276 <wink>.

> So in summary, it's not that I dislike integers being treated
> truly as objects, but rather that I want them to be clean objects.
> Objects whose methods behave in sensible ways for all instances of a
> class, not full of special defaults.

PEP 276 merely suggests that "for i in -3" should crash your program in the
same way that "for i in xrange(-3)" does <wink>.

Jim