Actually, I found : very clear as a newcomer to Python -- and you might laugh at me for this -- because it corresponded with my visualization of slices as, literally, vertical 'cuts' in the list. : is symmetrical and straight up-and-down, and for whatever reason this is what works for me when trying to visualize the slice.<br>
<br>I took on a job tutoring Python to students at Berkeley over the past two semesters, using this analogy (: doing the 'cutting': i.e. start at index 'start', cut, and take the rest until index 'end') worked, and : never got in the way. Using -> or .. would possibly help the mathematically-oriented people, but we get a lot of people from different walks of life, and I don't know that -> or .. would really help.<br>
<br>Also, the difference between -> and => is one line and a whole lot of
confusion. Given the ability to use ranges that may or may not include
the last element, that means for basically *every* given tuple, you can
slice it the same way with two different notations (by adding one to
the exclusive one, or subtracting one from the inclusive one). It's a terrible idea,
because now you have two ways to do the same thing, and a terrible
symbol to differentiate them: -> and => are both arrows, and there is no way I'm going to remember which is which if I'm not constantly using them -- and certainly not non-programming types. "There should be one-- and preferably only one --obvious way to do it." -- or else you get a bunch of conversations like so:<br>
<br>"well, you did it this way, why didn't you do it that way?"<br>"well, you can do it either way, actually."<br>"so they mean the same thing?"<br>"not quite, one's inclusive, one's exclusive, like I explained."<br>
"which one was which again?"<br>"sigh"<br>rinse and repeat.<br><br>I really don't see the problem with ':'. It's straightforward enough that even humanities majors (ahem, engineering major, forgive the snobbishness) get used to it after 10-15 minutes of face-to-face tutoring and examples. Changing the notation would at best save 5 minutes of tutoring time and piss off everyone who is either used to colon notation or actually *likes* it (like me), and at worst, add on a few extra minutes and *still* piss off everyone who is either used to colon notation or actually likes it. Not to mention you'd have to change the syntax and render all the code that uses slicing useless, pissing off untold legions of Python programmers. That is, unless you make it an optional syntax alongside the original, in which case you again have the (IMO, unpleasant) situation of being able to express the same thing in many ways. You'll have code that gets mixed together which uses one or the other, so now you're forcing people to know both ways of doing the same thing and being able to switch between both syntaxes when reviewing the code. Bad bad bad.<br>
<br>I just can't see this happening. I don't believe it has any merits except to possibly increase readability, and I take issue with the idea that it would in fact do so. Add to that the huge pain this would be either as a replacement syntax or as an optional syntax, and I think it would actually be a terrible idea.<br>
<br>--Andy <br>