On Apr 10, 2020, at 12:46, Chamoun Saoma <csaoma@gmail.com> wrote:
I have an idea to improve the python language through the creation of a new and very readable function.
################# def ranlen(x): #range of length of x return range(len(x)) #################
I find this less readable. The abbreviation “ran” frequently means “random”; occasionally it means other things; I can’t think of any place where it means “range”. Also, not every one-liner needs to be a builtin. Look at the docs to see how short the list is. That’s important—not for performance or for making it easier to write alternative implementations (although it does help both of those a bit), but because there’s so little to learn and keep in your head as a novice, or as an occasional user who comes back to Python every few weeks while mostly working in Kotlin, or whatever. The things that are there are all hard to get right, or easy to get wrong, or need access to internals, or can benefit from a custom C-optimized implementation in CPython, etc. There’s no builtins for identity (a function that returns its argument), dummy (a function that takes any args and ignores them and does nothing), inc (a function that adds 1), etc., because when you do happen to need them, you (even a novice or an occasional Python user) can write them yourself without even slowing down. Finally, far from being essential to many algorithms, this is actually an antipattern, or at least a code smell—most code that’s doing it should be doing something else: for x in xs: dostuff(x) xs = [x+1 for x in xs] xs[:] = [x+1 for x in xs] for i, x in enumerate(xs): xs[i] = x+i for x, y in zip(xs, ys): print(x + y) … and so on. The alternatives are almost always clearer, more declarative, harder to get wrong, more general (e.g., working with all iterables rather than just sequences), and more efficient than what you would have written with a loop over the range. So, what about, say, the case where you explicitly want to loop over the first len(xs) of ys, and it should be an exception if ys is too short rather than stopping early so you can’t use zip? Sure. You could actually use zip_longest with a sentinel fillvalue, or other stuff from itertools—but sometimes maybe a loop over the range does make more sense. (There’s a reason those functions are in itertools rather than builtins.) But those are unusual cases. Which means they usually deserve to be called out. A change that makes it look less visible and less unusual would actually be counterproductive.