Suggested feature: slice syntax within tuples (or even more generally)?

Andrew Robinson andrew3 at r3dsolutions.com
Mon Feb 25 09:45:38 CET 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