Wed, 12 Jul 2000 12:25:36 -0500
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
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
[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.