Okay, so this is really two requests in one, and they're both kinda
outlandish, but I'm gonna post them nonetheless:
I've always thought xrange() to be ugly; it looks to be a lot of typing
just to get an efficient loop over some numbers. Since it uses the same
'parameters' as the slice operator, I was thinking it would be neat if the
slice operator were to be syntactic sugar for the xrange operator.
Example:
for i in xrange(0,8,2):
pass
is equivalent to
for i in 0:8:2:
pass
Being the syntactic sugar it is, it does nothing but save typing (and
those extra colons do look slightly messy), but it does help unify the
syntax a bit. Now part two:
xrange() objects become an acceptable list index, operating as a slice
operator does. Example:
a[0:8:2] is equivalent to a[xrange(0,8,2)]
Since (correct me if I'm wrong) xrange()s just hold the three numbers
given them, this part (at least) shouldn't be too difficult to implement.
This would then allow the unification to be complete, so a[0:8:2] is
really the list 'a' being indexed by an xrange() object. Therefore a
change in the implementation would be fully backward compatible.
This type of indexing is slightly reminiscent of that of Matlab. I'm not
sure if the new xrange syntax would cause parsing problems; it might in a
statement such as:
for a in 0:8:
2:
pass
But I doubt that would be a problem, so long as the parser gobbles up as
much as it can.
Just a humble RFC. Don't reject me too harshly, I know it's a kinda silly
feature to request :) I just wanna give it a try.
outlandish, but I'm gonna post them nonetheless:
I've always thought xrange() to be ugly; it looks to be a lot of typing
just to get an efficient loop over some numbers. Since it uses the same
'parameters' as the slice operator, I was thinking it would be neat if the
slice operator were to be syntactic sugar for the xrange operator.
Example:
for i in xrange(0,8,2):
pass
is equivalent to
for i in 0:8:2:
pass
Being the syntactic sugar it is, it does nothing but save typing (and
those extra colons do look slightly messy), but it does help unify the
syntax a bit. Now part two:
xrange() objects become an acceptable list index, operating as a slice
operator does. Example:
a[0:8:2] is equivalent to a[xrange(0,8,2)]
Since (correct me if I'm wrong) xrange()s just hold the three numbers
given them, this part (at least) shouldn't be too difficult to implement.
This would then allow the unification to be complete, so a[0:8:2] is
really the list 'a' being indexed by an xrange() object. Therefore a
change in the implementation would be fully backward compatible.
This type of indexing is slightly reminiscent of that of Matlab. I'm not
sure if the new xrange syntax would cause parsing problems; it might in a
statement such as:
for a in 0:8:
2:
pass
But I doubt that would be a problem, so long as the parser gobbles up as
much as it can.
Just a humble RFC. Don't reject me too harshly, I know it's a kinda silly
feature to request :) I just wanna give it a try.