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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP Proposal: Revised slice objects lists use slice objects as indexes
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 | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP Proposal: Revised slice objects lists use slice objects as indexes
Forrest Voight wrote: Slice objects that are produced in a list index area would be different, and optionally the syntax for slices in list indexes would be expanded to work everywhere. Something like this was quite close to getting in a while back, but it was eventually dropped. Anyone advocating this should probably look back over the discussion and find out why. I think they were to be called range expressions or something like that. A point to consider is that iterating over a range of integers is actually quite a rare thing to do in idiomatic Python. It's much more common to iterate directly over a sequence of things you want to operate on. This is even more true now that we have enumerate(). So this proposal is addressing a fairly small set of use cases. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP Proposal: Revised slice objects lists use slice objects as indexes
On Mon, Mar 10, 2008 at 3:57 AM, Forrest Voight [EMAIL PROTECTED] 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP Proposal: Revised slice objects lists use slice objects as indexes
This would simplify the handling of list slices. Slice objects that are produced in a list index area would be different, and optionally the syntax for slices in list indexes would be expanded to work everywhere. Instead of being containers for the start, end, and step numbers, they would be generators, similar to xranges. Lists would accept these slice objects as indexes, and would also accept any other list or generator. Last, slice objects would be able to be added for multiple index ranges of a list. The new slice object would keep a list of ranges. Optionally, the 1:2 syntax would create a slice object outside of list index areas. It would be shorthand for slice, as [] is for list. This would create some confusion in loops and conditionals due to the colon being used for the end of the structure. (see last example) This would be incompatible with classes that define __setitem__ and __getitem__, and would need changes in how slices are handled in CPython. Therefore, this is probably a proposal for Python 3000. Examples: 1:5 1:5 list(1:5) [1, 2, 3, 4] list(1:5:2) [1, 3] s = 1:3 range(5)[s] [1, 2] 1:5 + 15:17 1:5 + 15:17 range(30)[1:5 + 15:17] [1, 2, 3, 4, 15, 16] range(100)[[1,2,3]] [1, 2, 3] range(100)[1,2,5] # maybe [1, 2, 5] for x in :15:3: print x # maybe 0 3 6 9 12 --- Forrest Voight ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP Proposal: Revised slice objects lists use slice objects as indexes
On Sun, Mar 9, 2008 at 7:21 PM, Forrest Voight [EMAIL PROTECTED] wrote: This would simplify the handling of list slices. Slice objects that are produced in a list index area would be different, and optionally the syntax for slices in list indexes would be expanded to work everywhere. Instead of being containers for the start, end, and step numbers, they would be generators, similar to xranges. 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. slice(1,4) slice(1, 4, None) [1,2,3,4,5,6][slice(1,4)] [2, 3, 4] I don't see how introducing new syntax would simplify indexing. Lists would accept these slice objects as indexes, and would also accept any other list or generator. Why lists should accept a list or a generator as index? What is the use case you have in mind? 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))? 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] 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
