I started to use Python not much after this article(2002?), and I wonder how much of those days' simplicity holds true. "Modern Python" is full of list comprehensions, generators and decorators. Not that's intrinsically bad, but it's not "executable pseudocode" anymore. Books as "Collective Intelligence" require you to know Python intricacies in order to understand it.
You really think Python is losing its simplicity? List comprehensions are much easier to read than a multi-line for loop (obviously, though, nesting list comprehensions is A Bad Thing for readability) - they are much simpler. Generators don't add simplicity!? Do you even know why you would use a generator, why does this run:
for i in xrange(1, 10000000000000): print i
and this doesn't:
for i in range(1, 10000000000000): print i
To make the range() example run, you have to use generative behavior anyway, in some form or another. Generators are a simple way of expressing that kind of algorithmic behavior.
(for the record, this little example is being ran on a machine with 2GB of ram)
I know that is a very silly use case for generators, particularly when range() is going to become xrange() anyways - but it is a perfect example of why generative behavior can make things simpler. The trade off is memory vs computation - range() builds the whole list then iterates over it; xrange() generates the next item in the list; use normal list construction when the list is knowably going to be small, use generative behavior when the list is going to be big!
Decorators make the language less simple????? A decorator gives you the ability to modify a function/class at runtime. Decorators have made my python code (where they are useful) much much simpler!! Decorators have given me another dimension to follow DRY with!! Decorators do make the implementation more complex but they make the code you write simpler - the trade off is very clear and the cons are almost non-existent.
If you think decorators are cool, try picking up Common Lisp or Scheme - Macros will rock your socks off.
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.
Simplicity 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.
I doubt people will argue that these features are useful, but they do increase Python's overall complexity by adding to the sum total one must learn to grok python.
There's a danger here: add too many "simplifications" and you get something complex.
I can agree with that (add too many simplifications...); that's why I've really fell for data-as-code in Scheme; the simplifications in that language are so broad that you don't have to /add/ simplifications. Whereas, with Python's (or any language that isn't homoiconic) "baked" syntax, you do have to add "simplifications" or "features".
> I started to use Python not much after this article(2002?), and I wonder how much of those days' simplicity holds true.
I started learning Python in 2003, I was really a programming newby, by I managed to get my first full-time programming job just 2 years later because Python made it that easy for a neophyte to get from 0 experience to getting paid to write code. List comprehensions are cool, and not that hard to grasp, but I agree, I sort of started losing track once people started using "generator that" or "decorator this" for every damn problem you threw at them.
That's hardly surprising, Minimalistic tools haven't been able to survive for a long time.
Problems change, programmers needs change. What was not necessary yesterday, might be very important today. You will have no option but to keep adding on things as they are needed.
I started out with vi, then found out I was better off using emacs. Its rather better to use something designed to be big from the scratch, than to be using some thing invented to be minimal but bloated later just to compete with others.
