Re: [Python-Dev] PEP Proposal: Revised slice objects & lists use slice objects as indexes
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
Forrest Voight wrote:
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.
You can already pass whatever items you like to __getitem__ for your own sequences without even touching the builtin slice(). You can even write a decorator to convert slice objects to the relatively arbitrary index iterators you appear to favour (I wish you good luck in getting those to play well with numpy and the myriad of other C extensions that rely on the existing extended slicing semantics, or explaining how they work to a Python novice - you're going to need it). That said, and as Alexandre already pointed out, this thread is off-topic for python-dev - please take it to python-ideas to thrash out whether or not it has any practical applications, and whether those applications (assuming they exist) are even remotely close to compelling enough to justify the pain involved in making such a major change to the core language. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
On Mon, Mar 10, 2008 at 3:57 AM, Forrest Voight <voights@gmail.com> wrote:
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
And what indices would the slice 1:-1 return, for example? Your proposal can't play well with slices including negative indices. Also, your desired use case of alist[indices] is already pretty well covered by [alist[i] for i in indices]. Alex
participants (3)
-
Alex Martelli -
Forrest Voight -
Nick Coghlan