By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,035 Members | 1,384 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,035 IT Pros & Developers. It's quick & easy.

Is it possible to merge xrange and slice?

P: n/a
Bas
Hi,

stupid question, but would it be possible to somehow merge xrange
(which is supposed to replace range in py3k) and slice? Both have very
similar start, stop and step arguments and both are lightweight
objects to indicate a range. But you can't do a[xrange(10,20)] and
'for i in slice(10,20)'. The only difference is see is some behavior
with infinities (e.g. object[3:] gives a slice(3,maxint) inside
_getitem_ , but I think this should not be a large problem
(xrange(0,infinity) could just yield a generator that never stops).

Which problems am I overlooking that prevent this?

Cheers,
Bas

Apr 30 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Which problems am I overlooking that prevent this?

1. Generators and slices serve two distinctly different tasks.
2. They may have the similar interfaces, but are implemented
differently. Each optimized for its specific task.

You are essentially asking "Why not do it?", to which I respond "Why
do it?". How does this consolidation of features improve Python?

Apr 30 '07 #2

P: n/a
On 30 Apr 2007 11:02:19 -0700, Bas <we*****@gmail.comwrote:
stupid question, but would it be possible to somehow merge xrange
(which is supposed to replace range in py3k) and slice? Both have very
similar start, stop and step arguments and both are lightweight
objects to indicate a range. But you can't do a[xrange(10,20)] and
'for i in slice(10,20)'. The only difference is see is some behavior
with infinities (e.g. object[3:] gives a slice(3,maxint) inside
_getitem_ , but I think this should not be a large problem
(xrange(0,infinity) could just yield a generator that never stops).

Which problems am I overlooking that prevent this?
Novel idea but how would slice(3,-1) work?

--
mvh Björn
Apr 30 '07 #3

P: n/a
On Mon, 30 Apr 2007 21:00:15 +0000, BJörn Lindqvist wrote:
On 30 Apr 2007 11:02:19 -0700, Bas <we*****@gmail.comwrote:
>stupid question, but would it be possible to somehow merge xrange
(which is supposed to replace range in py3k) and slice? Both have very
similar start, stop and step arguments and both are lightweight
objects to indicate a range. But you can't do a[xrange(10,20)] and
'for i in slice(10,20)'. The only difference is see is some behavior
with infinities (e.g. object[3:] gives a slice(3,maxint) inside
_getitem_ , but I think this should not be a large problem
(xrange(0,infinity) could just yield a generator that never stops).

Which problems am I overlooking that prevent this?

Novel idea but how would slice(3,-1) work?
Since the semantics of slice and xrange are different, you get very
different results:

>>slice(3, -1)
slice(3, -1, None)
>>range(10)[3:-1]
[3, 4, 5, 6, 7, 8]
>>xrange(3, -1)
xrange(0)

I don't see why you would want to mix'n'match slice objects and xrange
objects like Bas wants. I *think* what he's imagining is that if you say
something like:

alist[5:10] # a slice from a list

it should be the same as

alist[xrange(5, 10)]
That would, I think, only make sense if Python lists allowed sequence
arguments for slicing, as well as ranges:

alist[5] # gives the fifth element
alist[5:11] # gives the fifth through tenth elements
alist[5,7,10] # gives the 5th, 7th and 10th elements

Then alist[xrange(5, 10)] would be the same as alist[5, 6, 7, 8, 9].

I can see that could be useful, especially if (like slicing) it was
tolerant of errors. We could imagine list's __*slice__ methods accepting
either a single integer index, a slice object, or a tuple object.

The actual mechanics of what something like this would mean:

del alist[2, 4, 7, 1, 1]

I leave open.

While this could be interesting, I'm not sure that it belongs in slicing.
Although if not, that would mean growing three methods, a getter, a
setter and a deleter. Hmmm. Maybe slicing should be extended to accept
a sequence of indices...

.... enough dreaming... even if list slicing accepted a sequence argument,
passing an xrange object would not be the way to do it. That would be like
replacing:

result = alist[5:10]

with:

result = []
for i in (5, 6, 7, 8, 9):
result.append(alist[i])

--
Steven D'Aprano

May 1 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.