Suggested feature: slice syntax within tuples (or even more generally)?
Andrew Robinson
andrew3 at r3dsolutions.com
Mon Feb 25 03:45:38 EST 2013
On 02/25/2013 10:28 AM, Ian Kelly wrote:
> On Sun, Feb 24, 2013 at 6:10 PM, Andrew Robinson
> <andrew3 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20130225/5d3a9151/attachment.html>
More information about the Python-list
mailing list