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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4