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'). -- http://mail.python.org/mailman/listinfo/python-list