Arithmetic sequences in Python

[Xavier Morel]

Paul Rubin wrote:
> There's something to be said for that.  Should ['a'..'z'] be a list or
> a string?
To me, the most obvious result would be either a range object as a 
result, or always a list/generator of objects (to stay perfectly 
consistent). If a range of numbers translate into a list of numbers, 
then a range of characters should likewise translate to a list of 
characters, and a join would be required to get a regular string. This 
also adds more consistency between the two proposals of the initial post 
(e.g. list-based range and generator-based range), for while the 
list-based range could be expanded into a string a generator-based one 
couldn't/shouldn't, and the abstraction breaks (because two constructs 
that should be more or less equivalent become extremely different and 
can't be swapped transparently).

This would also be consistent with other languages providing a native 
"range" object such as Ruby or or Ada ranges.

The only thing that bothers me about the initial proposal is that there 
would not, in fact, be any "range object", but merely a syntactic sugar 
for list/generator creation. Not that I really mind it, but, well, 
syntactic sugar for the purpose of syntactic sugar really doesn't bring 
much to the table.

For those who'd need the (0..n-1) behavior, Ruby features something that 
I find quite elegant (if not perfectly obvious at first), (first..last) 
provides a range from first to last with both boundaries included, but 
(first...last) (notice the 3 periods) excludes the end object of the 
range definition ('a'..'z') is the range from 'a' to 'z' while 
('a'...'z') only ranges from 'a' to 'y').