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

[Rick Johnson]

On Thursday, February 14, 2013 4:01:39 PM UTC-6, steph... at gmail.com wrote:
> On Thursday, February 14, 2013 1:58:06 PM UTC-5, Ian wrote:
> 
> [snip: quote noise!]
> 

Dude! Please trim this quote noise from your posts. I know Google's quoting mechanism is buggy, but dammit man YOU'RE A PROGRAMER! There is no excuse for not trimming excessive newlines.

============================================================
 As to your slicing request.
============================================================

Anybody who knows me KNOWS that i love consistency! So i'm all for applying a slicing syntax consistently, however, i don't think your approach is the correct approach. 

To get you going in the correct direction: Ruby uses the  "s..e" and "s...e" (where "s" represents the start of the range and "e" represents the end of a range) as syntactic sugar for Range.new(s, e). Two dots create an /inclusive/ range and three dots create an /exclusive/ range. Anyway, enough tutorials, read the doc:

  http://www.ruby-doc.org/core-1.9.3/Range.html

Now, i am not suggesting that python should adopt the /exact/ syntax of Ruby, however, i /am/ suggesting that Ruby is more consistent with the range object than Python.

In Ruby:

...you can slice arrays with the range:
 
rb> a = [1,2,3,4,5]
rb> a[0..-1]
[1,2,3,4,5]
rb> a[0...-1]
[1,2,3,4]

...you can create a range of integers :

rb> r = 1..10 
rb> r.to_a()
[1,2,3,4,5,6,7,8,9]

...you can create a range of chars:

rb> r = "a".."d"
rb> r.to_a()
["a", "b", "c", "d"]

...you can use range in a loop:

rb> for x in 0...5;puts "#{x}th iteration";end
0th iteration
1th iteration
2th iteration
3th iteration
4th iteration

...but most importantly, you can do all these things in a consistent manner using a consistent syntax!

Python however has the stupid slice function and then sequence indexing, and no consistency between the two! Plus, the for loop uses the range function to create "lazy iterators" instead of employing a consistent "range" syntax.

Consistent syntax and consistent application are the biggest issues with Python ranges as they exist today. That's the starting point.