[Python-Dev] Ranges

[Paul Prescod]

Thomas Wouters wrote:
> 
> > How's this for obfuscation:
> 
> > [0:10][0:10][0:10]
> 
> Sure, but it's not more obfuscated than a long line of map(lambda ...
> reduce(filter(map(lambda ... ))) 

I'm just commenting on the overloaded syntax of list construction and
truncation. No big deal.

> > And arguing from analogy, shouldn't
> >
> > range(0:bignum)[0:10:2] be [0:10:2]
> 
> Yes, it should, but there is no way to enforce it, currently, because range
> can be shadowed by a local or global variable. And it doesn't have to be
> unintended, either. With range literals, that's no longer possible.

That's not what I mean. Ignore the range. My point is, if list
construction and truncation are going to be parallel, they should be
really parallel.

[0,1,2,3,4,5,6,7,8,10][0:5:2]==[0:5:2]

I don't understand "extended slicing" so I don't know why the former
doesn't work today.

> > You probably shouldn't be able to shadow most builtins period. 
> 
> Why not ? It would introduce a number of problems: adding new builtin
> functions would be as cagey as adding new reserved words (in effect, all
> builtins *become* reserved words.) 

I said "most", not "all". Over time they could migrate from being
builtin to being non-overridable. No one should define a function (not
method, but function) called "map" or "dir". In practice, I haven't seen
such a thing. If we make a "tuples" function then for a year or two it
is fair game for overriding, the it becomes frozen.

> For that reason I think it's better to live with xrange() ;)

You could also use a lazy list comprehension (if we made list
comprehensions lazy):

[for x in [0:10:20]: x]

That would make people think twice about using xrange (as it
should...xrange isn't usually as efficient as they think!)
-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/~perlis-alan/quotes.html