3 ms·

Comparing it with PHP is unfair… to PHP. The amount of hard work that the PHP community has done to advance and keep their language relevant is impressive and a

Comparing it with PHP is unfair… to PHP. The amount of hard work that the PHP community has done to advance and keep their language relevant is impressive and admirable, and Python is perhaps the most extreme counterexample there is. The Python community has spent the last 15 years refusing to improve in any meaningful way, or to learn anything from their peers. As someone who used to choose only jobs that would let me work with Python, I’ve gone through every phase of grief, and now just try to forget that it exists.

mixmastamyk 1mo ago
Lol, Python has had incredible improvements over the last decade plus, while uv fixed packaging. It's the best/comprehensive glue language ever made, even with a few remaining warts.
rmunn 1mo ago
Most of the time downvoters don't explain their downvote, but I'll explain mine. I voted this comment down because it's just plain incorrect.I worked with PHP for nearly ten years (and I never want to go back). Maybe PHP has improved since I worked with it (PHP 7.4 was the most recent version when I last worked with it, I have never used PHP 8), but I doubt it. But to describe the Python community as "spen[ding] the last 15 years refusing to improve in any meaningful way" is just laughably wrong. I can't give details as I haven't been doing much Python work, but even so I know of multiple changes, such as the typing system, or packaging improvements, which have significantly improved the language AFAICT. If there's a reason why you would not consider those to be "improv[ing] in any meaningful way", please enlighten me.
- mixmastamyk 1mo ago
  You mentioned two biggies, but also the GIL removal, async, performance improvements, f-string, walrus, fast dicts w. merge ops, data classes, pattern matching, friendlier repl, and hundreds of smaller yearly improvements.
  - rmunn 1mo ago
    Pattern matching? Nice, I'd managed to miss that one completely, as well as the fact that Python had introduced dictionary-merging (according to a quick search, Python 3.9 introduced the | (pipe) operator for dict unions). I did know about the others you mentioned, but couldn't call them to mind when writing my comment. But reading through a Python script that I had Claude Code write for me taught me another one: apparently there's now a / operator on strings, because Claude wrote `path = "some" / "dir" / "filename.txt"` without importing anything outside of the stdlib. I presume it is shorthand for calling os.path.join and will therefore apply the correct path separator on Linux vs Windows.
    - mixmastamyk 1mo ago
      Yes, that's a Path object from pathlib. It has been around for while but likely still qualifies, site says from 3.4.
      - ModernMech 1mo ago
        You are both focusing on Python improving in any way but the person you're responding to said "improve in any meaningful way, or to learn anything from their peers" Which I will say is overstated but I can see where they are coming from even when you bring into scope things like types, async, etc. First types. This is what the type hints in Python allow you to do: def foo(x: int) -> int: return x foo("hello") We can say that this is great Python has type hints, but at the same time the lesson they learned is wrong because the feature to have isn't type hints but actually enforcing them so the above code cannot be written. In my eye, this is an anti-feature. Second async, this is also the wrong lesson to have learned from other languages. Adding async/await is a bandaid over the problem that the synchronous imperative model clashes with asynchronous distributed semantics. The async/await keyword are a way to try to bridge between the two, but it creates a "function coloring" problem that all these languages which added async/await have. The lesson Python should have learned is to not add these keywords and go back to its glue language root, allowing actually natively asynchronous languages to coordinate asynchronous processes, while Python code handles the synchronous core. Python doesn't have to be everything, the wrong lesson was to try to be the one language to rule them all. You also brought up the packaging improvements, which I feel were the wrong lesson learned. The problem with the Python packaging ecosystem is well known since it's been expressed in the XKCD comic. The lesson from other languages is: one blessed compiler toolchain integrated into the packaging story makes for a better user experience. This is the npm, cargo lesson. For Python to really learn it, uv or equivalent would be the blessed way of managing Python projects. Instead it's still a very fragmented landscape with many competing solutions, which goes against Python's own zen. Moving on to pattern matching, again I feel the wrong lesson was learned. Pattern matching is a feature from the functional paradigm that in my opinion became more popular with developers when they became exposed to it in Rust, and so Python joined in and added the feature as well. But the reason it's such a nice feature in Rust is because it will refuse to compile any code that does not do exhaustive matching on all variants. This is great because it catches problems early and forces you to consider the non happy path where things can error. So pattern matching alone isn't the feature it's pattern matching PLUS structured Enums and exhaustive patterns. So in Python you can do this: x = 3 match x: case 1: print("one") case 2: print("two") print("done") Output will be "done" rather than an error on the match, which is what should happen if they had learned the right lesson, because without exhaustive matching this is no better than an if or switch. Again I consider this an anti-feature -- better to not have at all if it doesn't work as expected. Anyway, I'm not trying to say Python is bad, I'm just saying I get where the other poster is coming from when they say Python has refused to learn the right lessons. Although I would not agree they haven't improved a lot over 15 years.

mixmastamyk 1mo ago

Lol, Python has had incredible improvements over the last decade plus, while uv fixed packaging. It's the best/comprehensive glue language ever made, even with a few remaining warts.

rmunn 1mo ago

Most of the time downvoters don't explain their downvote, but I'll explain mine. I voted this comment down because it's just plain incorrect.I worked with PHP for nearly ten years (and I never want to go back). Maybe PHP has improved since I worked with it (PHP 7.4 was the most recent version when I last worked with it, I have never used PHP 8), but I doubt it. But to describe the Python community as "spen[ding] the last 15 years refusing to improve in any meaningful way" is just laughably wrong. I can't give details as I haven't been doing much Python work, but even so I know of multiple changes, such as the typing system, or packaging improvements, which have significantly improved the language AFAICT. If there's a reason why you would not consider those to be "improv[ing] in any meaningful way", please enlighten me.

mixmastamyk 1mo ago
You mentioned two biggies, but also the GIL removal, async, performance improvements, f-string, walrus, fast dicts w. merge ops, data classes, pattern matching, friendlier repl, and hundreds of smaller yearly improvements.
- rmunn 1mo ago
  Pattern matching? Nice, I'd managed to miss that one completely, as well as the fact that Python had introduced dictionary-merging (according to a quick search, Python 3.9 introduced the | (pipe) operator for dict unions). I did know about the others you mentioned, but couldn't call them to mind when writing my comment. But reading through a Python script that I had Claude Code write for me taught me another one: apparently there's now a / operator on strings, because Claude wrote `path = "some" / "dir" / "filename.txt"` without importing anything outside of the stdlib. I presume it is shorthand for calling os.path.join and will therefore apply the correct path separator on Linux vs Windows.
  - mixmastamyk 1mo ago
    Yes, that's a Path object from pathlib. It has been around for while but likely still qualifies, site says from 3.4.
    - ModernMech 1mo ago
      You are both focusing on Python improving in any way but the person you're responding to said "improve in any meaningful way, or to learn anything from their peers" Which I will say is overstated but I can see where they are coming from even when you bring into scope things like types, async, etc. First types. This is what the type hints in Python allow you to do: def foo(x: int) -> int: return x foo("hello") We can say that this is great Python has type hints, but at the same time the lesson they learned is wrong because the feature to have isn't type hints but actually enforcing them so the above code cannot be written. In my eye, this is an anti-feature. Second async, this is also the wrong lesson to have learned from other languages. Adding async/await is a bandaid over the problem that the synchronous imperative model clashes with asynchronous distributed semantics. The async/await keyword are a way to try to bridge between the two, but it creates a "function coloring" problem that all these languages which added async/await have. The lesson Python should have learned is to not add these keywords and go back to its glue language root, allowing actually natively asynchronous languages to coordinate asynchronous processes, while Python code handles the synchronous core. Python doesn't have to be everything, the wrong lesson was to try to be the one language to rule them all. You also brought up the packaging improvements, which I feel were the wrong lesson learned. The problem with the Python packaging ecosystem is well known since it's been expressed in the XKCD comic. The lesson from other languages is: one blessed compiler toolchain integrated into the packaging story makes for a better user experience. This is the npm, cargo lesson. For Python to really learn it, uv or equivalent would be the blessed way of managing Python projects. Instead it's still a very fragmented landscape with many competing solutions, which goes against Python's own zen. Moving on to pattern matching, again I feel the wrong lesson was learned. Pattern matching is a feature from the functional paradigm that in my opinion became more popular with developers when they became exposed to it in Rust, and so Python joined in and added the feature as well. But the reason it's such a nice feature in Rust is because it will refuse to compile any code that does not do exhaustive matching on all variants. This is great because it catches problems early and forces you to consider the non happy path where things can error. So pattern matching alone isn't the feature it's pattern matching PLUS structured Enums and exhaustive patterns. So in Python you can do this: x = 3 match x: case 1: print("one") case 2: print("two") print("done") Output will be "done" rather than an error on the match, which is what should happen if they had learned the right lesson, because without exhaustive matching this is no better than an if or switch. Again I consider this an anti-feature -- better to not have at all if it doesn't work as expected. Anyway, I'm not trying to say Python is bad, I'm just saying I get where the other poster is coming from when they say Python has refused to learn the right lessons. Although I would not agree they haven't improved a lot over 15 years.