But lately I think the language has grown more complex, new functionality is being added all the time.

I feel this is unfortunate in some ways. It's not so true anymore that "there's one way of doing things, and it's obvious", which was one of the best things about the language IMHO.

My feeling is the language developers should slow down a bit on new features and focus on packaging and speed.

Still, it's a great, flexible language, and I think it will keep on being relevant for a long time.

I hope that your career flourishes and you write many attention grabbing pieces which predict, Cassandra-like, the future of our beloved industry.

But whenever that future arrives, I will be there, slinging Python code, because I love this language. These colors don't run. Nobody puts baby in a corner. I love Python and I'm taking this love to the grave... and beyond. I will be programming in Python when I am a soul living in outer space.

Nothing can stop this love, my friend. It is too good, too deep - I've done too many things with it, to be bothered by runtime efficiencies or however it fails in comparison with Haskell or Rust. I respect everyone's right to disengage and learn Rust or whatever but like I said, this is the bus I'm riding out on.

Does Python have its issues? Yes. Is it suitable for everything (the article mentions mobile development)? No. Does that mean it's going to be superseded? No. Those things don't necessarily even mean it should be superseded, and that's a much weaker claim.

* Performance is not as dire as the author suggests. It’s just not the biggest priority compared to say V8. There’s a good amount of low hanging fruit, and hot paths in high-perf libraries are typically written in C and just instrumented in Python.

* Whitespace syntax is a non-issue to anyone but beginners in their first week of programming.

* Lambdas being not very good syntax most of the time doesn’t affect anything since you never are required to use them. Just create a function or any other Callable.

* Python being dynamically typed is a style choice, not a deficiency. There are trade-offs but “dynamic with statically checked type annotations” whether it’s Hack, Typescript, or Python is insanely productive.

Nothing to really say about mobile. Totally valid and there’s not a whole lot of work being done on getting it there.

Python was never dynamically scoped. Before Python 2.2 it had a three-level static scoping system, and nested functions didn't have any access to variables from their parent function's scope.

It kind of approaches recognizable real issues, but with most of the details misstated on every point. Python can change bindings in outer scope, statement/expression distinctions are common in languages (but Python’s limited anonymous functions make them more acute in that context in Python), contrary to the contrast the article attempts to draw, JavaScript—like Python—was not designed for mobile and Python—like JavaScript—has frameworks that were. The article also jumbles issues related to static typing, compilation, and performance (and given the existence of—incomplete but evolving—static typecheckers and performance-boosting native code compilers for python, also treats them as more fundamental and immutable than they are.)

This doesn't seem true in my experience.

First off, I'm glad the author phrased it as time "you'll need ... to complete a task," because in many cases that's a more important measure than any benchmark of the code itself. Given some data and a question about the data, I can almost certainly answer the question faster in a Python REPL or notebook than in any language which needs to be compiled. Sure, it might take ten seconds instead of one to do the math, but it takes much more than nine seconds to write a complete program in a standalone editor and compile it and run the output and look at it.

Second, for tasks that are I/O-heavy and not computation-heavy, the fact that Python is interpreted doesn't really matter. If you're making a request to an API that takes 300 ms to respond, it hardly matters if processing the response takes 1 ms or 10.

Finally, as the author mentions, there are several compiled Python extensions like NumPy.

> Python tried to transition to static scoping, but messed it up. Usually, inner scopes — for example functions within functions — would be able to see and change outer scopes. In Python, inner scopes can only see outer scopes, but not change them.

This is not true:

    >>> def a():
    ...   result = []
    ...   def f(x):
    ...     result.append(x ** 2)
    ...   for i in range(10):
    ...     f(i)
    ...   return result
    ... 
    >>> a()
    [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

    >>> def a():
    ...   x = 0
    ...   def f():
    ...     nonlocal x
    ...     x = 1
    ...   f()
    ...   return x
    ... 
    >>> a()
    1

    type person = { name : string; age : int }

    let greet { name; age } =
      Printf.printf "Hello, %s aged %d!\n" name age

    type person = { name : string; age : int } let greet { name; age } = Printf.printf "Hello, %s aged %d!\n" name age

JavaScript based platforma are using … a language that was specifically created for mobile app development?

Why compare a language with a platform anyway? Python <-> JavaScript or dart, not react or flutter.

Types in python is very much just documentation and isn't enforced at compile time.

Of course there are people who believe that types don't matter. I guess to them there isn't really any objective criteria to judge a language, just whatever syntax they happen to like

Now that Guido van Rossum has joined Microsoft I'm looking forward to seeing if speed improvements can be made: https://twitter.com/gvanrossum/status/1326932991566700549?la...

Python is slow, but PyTorch is fast, GBTs are fast, Cython is fast, Pandas and Numpy are fast (and even faster libraries or even basic joblib code can parallelize these).

Anything that needs to be fast either is or can be made fast--and most compute in data-intensive applications exists inside these optimized libraries anyway.