3 ms·
I do understand and use that features. My point it's that they aren't obvious. One of Python strengths was that any programmer could look at it and know what wa
by samuel 15y ago
I do understand and use that features. My point it's that they aren't obvious. One of Python strengths was that any programmer could look at it and know what was going on, and, for newbies, it was much easier to learn.
I'm among the few unimpressed by list comprehensions. I use them because they're "idiomatic", but I'm equally comfortable with good old map(), which, I admit, it may be equally foreign for imperative-only programmers.
About the xrange() example, IIRC the iterator protocol predates generators, and probably is easier to grasp since the state is handled explicitely.
Decorators, as Lisp macros, are powerful but, if not handled with care, the source of very subtle bugs, because the thing you're looking at(the decorated function) doesn't do what it seems to do.
Anyway I'm not arguing against this artifacts, just pointing that, some of the merits of Python that were true a decade ago, aren't anymore.
- Ixiaus 15y agoSimplicity doesn't always make something more learnable or more readable. Scheme (R5RS) is a good example of a minimalist language that isn't necessarily easy to read when compared with Python's readability; same is said about its "learnability". I nitpicked those features because while I would agree list comprehensions aren't as readable/learnable to a new user, they do make the language simpler in that it increases the expressiveness of the language for a common pattern. To each his own, I like both list comprehensions and map() - not sure if I really take a side on either one... My example of xrange() in arguing for generators was a bad one because you're right, it is an iterator. I still feel like generators increase the expressivity of the language and therefore make it "simpler" - but again I will agree with you that new users will find it less readable and less learnable (to begin with though!). Decorators I will completely agree, are new user unfriendly and are a complex language feature - I suppose I was arguing for reduced program complexity rather than language simplicity in the context of the decorator addition.