Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #39894
| Date | 2013-02-25 08:45 +0000 |
|---|---|
| From | Andrew Robinson <andrew3@r3dsolutions.com> |
| Subject | Re: Suggested feature: slice syntax within tuples (or even more generally)? |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.2508.1361810871.2939.python-list@python.org> (permalink) |
[Multipart message — attachments visible in raw view] - view raw
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.
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: Suggested feature: slice syntax within tuples (or even more generally)? Andrew Robinson <andrew3@r3dsolutions.com> - 2013-02-25 08:45 +0000
csiph-web