is Python obsolete?

tl;dr: I stand by my point, Python as a language is obsolete, and the reason people still use it are purely based on the ecosystem around it.

> The approach of "absorb all the solutions from other languages"
I don't recall suggesting anything like that. I merely observed that I don't see which problems Python as a language has interesting solutions for, while I do see that the problems they're currently solving are consistently problems that other languages have solved years ago, often in better ways.

> Note -- this proposal doesn't need *any* new syntax, it's just a new standard library module.
You say that like it's a good thing, but I'm not convinced it is. It uses a decorator to money patch some boilerplate code into the annotated class. While this use of monkey patching is probably fairly innocuous, I don't think it's a good idea in general. It potentially makes it very hard to figure out where some method came from, and it eludes my why somebody who worries about multi-line lambdas making code hard to read would tolerate it.
In Scala, this kind of thing can be done using macros. Classes can be annotated and have their ASTs transformed with arbitrary code, but the crucial point here is that this happens at compile time, rather than at runtime. So you can't do all the nasty things that monkey patching allows, like patching a class that doesn't belong to you etc., making it a cleaner approach in general.

> It's not as if Python coders have been missing this functionality, we've just been using 'attrs' and other third-party libs that do the same thing.
Well yes, but I would argue that such basic functionality really should have been included in the code language a long time ago, simply because if it's not, many people won't use it. Either because they don't know about it or because they don't want to add that dependency.

> - For UIs, network-handling code etc., you need asynchronous code but don't really care if it runs interleaved on the hardware. That's easy now with the async/await statements.
Async/Await is yet another one of the many problems that Python solved years after other languages and in a less useful way. As far as I can tell, this stuff is simply Monad syntax, except it doesn't generalize to other Monads, making it much less useful. When Scala introduced Futures in 2.10, that was a pure library change, because the language already supported Monads, and you don't really need anything beyond that on a language level. So the fact that Python needed to be extended to support that really only proves my point.

> - For maths/scientific/machine-learning code, it would be daft to do the heavy calculations in any interpreted language. There's a huge range of lower-level libraries that can do that (often on the GPU) with good Python bindings, and they drop the GIL while doing that work and/or use parallelism internally, so such things do scale fine across cores.
If you have to resort to (libraries written in) another language to implement performance-sensitive bits of your program, then why bother with Python in the first place? I suspect that most people who like it do so because they compare it to mainstream languages that they know, like Java or C, and they've never worked with more more modern designs like Haskell, Ocaml or Scala.
I'd also like to point out that plenty of attempts were made to improve Python's performance, like Pyston for instance. Like it or not, performance matters, and Python isn't doing well. The reason why Dropbox dropped Pyston is also telling: they simply started switching to Go instead. So I think it's an illusion to think all performance problems can be solved by using some library written in C.

> - For web servers, it's nice to use Python for everything; no cheating and calling out to libs from other libraries. In that case, however, you're handling hundreds of unrelated requests, so each one can have its own process and GIL and again it scales fine across cores.
Well great, but every language can do that, so it's not really an argument for Python at all. I realise it probably wasn't meant to be, but I'd like to hear an argument *for* Python at this point, rather than explanations about why (you think) the problems other people see don't matter.

> - It keeps the parser simple,
Aside from the fact that I can't see how having an additional unnecessary syntactic category (statements) simplifies anything, I don't see why I should care since I don't need to implement it. In fact the whole idea of high-level programming languages is that the effort of implementing them is outweighed by the productivity gains of the users.

> and helps avoid people writing inscrutable code.
I don't buy that, sorry. I really don't think that the way to avoid hard-to-comprehend code is to place arbitrary limitations on the syntax. On the contrary, it will make things more awkward.

> Statements that would make sense as expressions already have such a version (comprehensions, lambda).
Think about this: why do you need for loops when you have comprehensions? Well, you may want to do things in the body of the loop that require statements; if statements didn't exist, you wouldn't really need for loops! Well, except of course that comprehension syntax in Python has another problem: in an expression like `[foo(x) for x in xs]`, the x variable is used before it's introduced, making things hard to follow if the "loop body" is a significantly larger expression than `foo(x)`.
Both of these problems can be fixed, hence Scala only has one syntax for that, and it supports arbitrary Monads, which is why it doesn't need language support for asynchronous programming. My earlier example is written `for (x <- xs) yield foo(x)` in Scala. The fact that Python needs for loops in addition to comprehensions is really just a symptom of the problem I mentioned.

> - Because a lambda is just a function definition, but one that's an expression so it can be written inline. Who wants multi-line functions defined inline? Particularly, who'd want to read that sort of code?
I want that, because I don't see why a multi-line function would be any less useful in an expression context than anywhere else. Scala supports this and I can tell you from years of experience with the language that it doesn't make the code any less intelligible.

> The generator form already *does* generalise like that.
No, it doesn't.

> `Zep(foo for foo in bar)` lets you construct arbitrary classes with a comprehension and no intermediate container.
What you're doing there is merely passing a generator as a constructor parameter, it doesn't change the fact that comprehension syntax will always yield a generator (or list etc.). Which is actually really odd, since most Python syntax *can* be generalized with magic methods like __add__ etc. Here's how it could be done in Python:
http://blog.sigfpe.com/2012/03/overloading-python-list-co...
Alas, the language currently doesn't include that :-(