On 02/25/2013 10:28 AM, Ian Kelly wrote:
On Sun, Feb 24, 2013 at 6:10 PM, Andrew Robinson
<andrew3@xxx> wrote:
I've read through the whole of the subject, and the answer is no,
although I
think allowing it in (::) is a *very* good idea, including as a
replacement
for range or xrange.
s=1:2:3
for i in s:
for i in (1:2:3) :
Eww, no. I can appreciate the appeal of this syntax, but the problem
is that ranges and slices are only superficially similar. For one,
ranges require a stop value; slices do not. What should Python do
with this:
for i in (:):
The same thing it would do with slices.
A slice is converted to an iterator at the time __getitem__ is called;
it in fact has methods to compute the actual start and stop, based on
the parameters given and the size of the object it is applied to.
Slices are, therefore, *not* in fact infinite;
Intuitively, it should result in an infinite loop starting at 0. But
ranges require a stop value for a very good reason -- it should not be
this easy to accidentally create an infinite for loop.
It wouldn't, but even if it did an *effective* infinite loop is already
easy to create with xrange:
a = 10
...
a = 1.1e12
...
for i in xrange( int(a) ):
and, besides, the same is true with other constructions of loops....
while a: # Damn easy, if a is accidentally true!
I can go on.... but it's rather pointless. Build a better protective
device, and the world will find a luckier idiot for you. There isn't
enough concrete to stop terrorists -- and not enough typing to stop bad
programmers and pass the good ones.
So I would
advocate that this should raise an error instead. If the user really
wants an unlimited counting loop, let them continue to be explicit
about it by using itertools.count. On the other hand, this would mean
that the semantics of (:) would be different depending on whether the
slice is used as a slice or a range.
No, it would be different depending on whether or not it was applied to
an iterable; which is already true.
The next problem you run into is that the semantics of negative
numbers are completely different between slices and ranges. Consider
this code:
s = (-5:6)
for i in s:
print(i)
for i in range(6)[s]:
print(i)
I don't find this difference to be necessary, nor objectionable.
It is less inconsistent, in my view, to allow that
([ 1,2,3,4,5 ])[-1:2] produce [5,1,2] than an empty list;
and ([ 1,2,3,4,5])[2:-1] does produce an empty list.
I have been looking for actual programs that this would break for over
two months now, and I haven't been finding any. I am willing to run any
mainstream application you can find on test-patched python!
Intuitively, both loops should print the same thing. After all, one
is using the slice s as a range, and the other is using the very same
slice s as a slice of a sequence where the indices and values are the
same.
YES! I like the way you think about consistency and intuition.
This expectation fails, however. The first loop prints the
integers from -5 to 5 inclusive, and the second loop only prints the
integers from 1 to 5 inclusive.
For these reasons, I disagree that allowing slices to be implicitly
converted to ranges or vice versa is a good idea.
I respect your opinion and agree to simply disagree.
--
http://mail.python.org/mailman/listinfo/python-list
