I am not sure what you are trying to propose here. The slice object isn't special, it's just a regular built-in type.
The idea is to have slice objects be generators. You could make a slice like 1:10:2 , and that would make a slice object which could be used as a list index. The list would return a list with the corresponding item for every index in the generator. Then, lists could transparently be used as list indexes, or you could supply your own generator instead of a slice object.
I don't see how introducing new syntax would simplify indexing.
It would move the slice logic from the list to the slice object. Now the slice object is just a container, but with this it would be useful.
Why should lists accept a list or a generator as an index? What is the
use case you have in mind?
For example, a multiple selection box's selection would be changed into its values by supplying the chosen indexes into a list of values.
Optionally, the 1:2 syntax would create a slice object outside of list index areas.
Again, I don't see how this could be useful...
list(1:5) [1, 2, 3, 4]
list(1:5:2) [1, 3]
list(range(1,5,2))?
It would only be useful as shorthand for xrange, but its addition capabilities would be useful.
range(30)[1:5 + 15:17] [1, 2, 3, 4, 15, 16]
This is confusing, IMHO, and doesn't provide any advantage over:
s = list(range(30)) s[1:5] + s[15:17]
I don't think it's confusing. Also, an advantage would be if the slice object were being automatically generated, this would simplify the code.
If you really needed it, you could define a custom class with a fancy __getitem__
class A: def __getitem__(self, x): return x
A()[1:3,2:5] (slice(1, 3, None), slice(2, 5, None))
P.S. You should consider using the python-ideas (http://mail.python.org/mailman/listinfo/python-ideas) mailing list, instead of python-dev for posting suggestions.
Cheers, -- Alexandre