> The standard interpreter bring rather slow;
I'm tired about this one.
In the last 13 years, 97% if the projects I worked on didn't need Python to be any faster, it was not the bottleneck. The remaining ones could leverage some solution to bypass the problem. Python speed is indeed an issue to a few people, but it's not the red flag I can read about here and there.
I've been hearing this argument for ever. PHP is slow. Java is slow. The first one powered the Web for 10 years, the second one is the most used language is the world. A lot of time this argument is like hearing "I want a pony".
Actually the rare persons I met really needing speed never complained. They are usually hardcore professionals, and are already working on solutions.
Let's now talk about solutions.
Python is an interpretted and very dynamic language. It's though to speed up. If you look at the C code, you'll see the Python VM is quite well optimized already.
Now the author says:
> no real improvements are being made for some reason
But there have been:
- psyco
- unladden shallow
- stackless
- numpy and a lot of compiled extensions
- pypy
- pyston
- pyjion
- nuikta
- cython
- numba
People ARE actively working at the problem. It's a HARD problem which is why we don't have yet a definitive solution. And a lot of people working on it are non paid for this.
Yeah, JS became faster. You know how ? Google spent millions and hire a bunch of geniuses just to do it.
In 2011, the Python Software Foundation had $750,000 to spend for the whole operation, including maintaint pypi, the documentation, the official website, the conferences they do and the various grants they provide. Even the few dev that are paid to work on Python (e.g: Guido) have to do it only part time.
So the authors worked with Python for 10 years. He made a living out of a free exceptional software and complain about a problem he may even doesn't have while people are working their ass off to solve it. And we writes an aggressive rant about it.
> Parallelism is very bad on CPython and PyPy
Yes, again, this is a HARD problem. Python is very old. Older than Java. We only had multi-core recently. We can't destroy mono-core perfs to get multi-core, and have to mainteaint a legacy code base.
We also have:
- a good multiprocessig story;
- 2 good async stories;
- tooling to pre-spaws, manage and scales processes;
- tooling to create task queues.
So while the community is trying, for free, to solve the problem. We have solutions. It's not perfect. But again what's the point of complaining like an hungry child à 4 o'clock unhappy it's not yet dinner time ?
> asyncio does not seem very well integrated, and does not seem as useful as libraries like eventlet. They seem to have wanted to reinvent Twisted, but did so half-assed and did not include useful protocols (Twisted has line-based protocols, HTTP, etc. built in and easily subclassable.)
What is he talking about we just got it ? How do you expect it to be well integrated yet ?
And Twisted is a framework (a very hard to use one) while asyncio is a low level lib.
eventlet doesn't let you choose where to switch context, it's basically like threads. We already have threads.
> Quite a few legacy projects are written in Python 2, and it can take some work to port them. This is particularly a pain for libraries where I expect to pip install them and have them "Just Work".
When the last time didn't that happen for anybody ?
Seriously:
http://py3readiness.org/
I've been coded in Python 3 for the last 2 years. It happened twice. Both time I was able to convert the code base in a few minutes. I said minutes. Not hours.
> There is an official tool 2to3 which does not work in all cases.
And the break in your car doesn't work in all cases either. Still it's a nice break.
Plus you got six and Python-future. Converting any pure-python code base is not hard. Compiled extension is harder, but my guess the author never needed to code one.
And i'll say it again...
People have 15 bloody years to migrates. It's not like JS tools breaking every 3 months. It's not like PHP skipping the version 6 or Perl taking 10 years to get V6.
No. Python 3 arrived quickly after many warnings. Then tools, tutorials and a looooooooooooot of time have been provided.
This is nowhere Python's fault. It's the best damn migration story I've ever witnessed in my life.
My only grudge on Python 3 is that it didn't break ENOUGH. I wished for stuff to have changed more.
> The standard library is sometimes inconsistent
One of my pet peeves as well.
> The BDFL himself, Guido van Rossum, has infamously declared that he does not like functional programming (odd, considering the language is built around FP concepts), and that map/reduce/filter should not be in the language. Well -- in my opinion that is a grave mistake, but more importantly the language suffers.
The author doesn't like the style of the language. So it's a matter of taste.
Well I like it that way.
Now what ?
> reduce is now tucked away inside the functools module (as of Python 3), even though it is the only one of map/filter that is not replaceable by list/set/dict comprehensions! Yet map and filter are still in the base global environment. What sense does that make?
Yes it does because reduce is seldom used. Grep github and you'll see. map and filter are still in the built-ins because people like the author complained a lot on the mailing list.
Yet, the majority of code base I read, including most of the libs I use (I spend a lot of time reading the content of my site-packages) don't use map/filter since we got comprehensions.
> I often find myself reimplementing flatten as flatten = lambda xs: itertools.chain.from_iterable(*xs)
Use comprehensions to flatten. Learn you language for van Rossum' sake !
(y for x in xs for y in x)
> The lack of tail call optimization in most implementations makes writing tail recursive algorithms rather pointless, unfortunately, even when they may be more legible than their iterative counterparts.
> There is no standard way (even in functools) to compose functions. There is partial application via functools.partial, at least...
Again it's because recursivity is not encouraged in Python. It's the philosophy of the language. One can dislike it but it's not a Python problem, it's a Python decision.
I stay in Python precisely for this. Everytime I go read functional heavy code, it's hard to read. I'm an expert coder and trainer. I'm paid up to 900€/day. Most code should be easy to understand given my experience. When it's not, I consider that a bug.
Functional lovers write smart code. I hate reading smart code. I want code that is easy to debug.
If you really need TCO, like when implementing a state machine, there are solutions:
http://neopythonic.blogspot.fr/2009/04/final-words-on-tail-c...
Not as elegant, but good enough since it's a rare occurence you do need it. Again. Rare.
The language is optimized for regular use cases and readability, not smart formulas.
> Lambda is awful
Lambda is wonderful. It keeps people from writting budge inline callback like they do everywhere else. It's the best decision Guido every took.
Xith lambda + decorators + list comprehension, the need for multi-lines callbacks is not huge.
You want more ? Write a regular function. How hard is it ?
It's not hard. So eventually it's matter of...
... wait for it ...
taste.
I would have liked a shorter keyword though. But I can live with it.
> Inadequate data modelling facilities
"Inadequate data modelling facilities" because classes are verboses ? Overkill title much ?
Beside, if you just need a container, you use a dict in Python. Not a class. At most you use SimpleNamespace:
>>> from types import SimpleNamespace
>>> SimpleNamespace(a=1, b=True)
namespace(a=1, b=True)
But again this is "pony"-worth complaining.
I do think classes are too verbose in Python (I use the attrs lib because of this). But this is childish.
algebraic data type and the whole dunder methods vs interfaces are more interesting debates.
> Lack of switch (or match)
> No, dicts with lambdas (see above) are not a replacement. No, long if-else chains are not a replacement. I want a nice way to match on data (preferably richly -- as with ADTs, ranges, ...) and associate matches with logic
Yes they are for switch. Since is the most overrated statement after go to. It's uneeded, as you can express it's logic perfectly without it. And again, "rare use case". There is nothing wrong with a bunch of if or a dict.
Now for match, it's a different story. Pattern matching would be a nice addition for Python IMO. But again things like:
> Please do not suggest awful hacks to do this, and fix your language instead.
Is arrogant and ignorant.
The mailling list have been discussing it for years. It hasn't happen because there no such thing as a magic way to make everybody agree then implement it and maintain it for free.
Things have cost. People have taste. Code base have legacy requirements.