8 ms·

Some of the author's points are valid. However, many are subjective preferences, and some are gripes without solutions, and others make it difficult to understa

by koliber 10y ago

Some of the author's points are valid. However, many are subjective preferences, and some are gripes without solutions, and others make it difficult to understand the author's underlying philosophy. My main critique is that the author added this statement that puts a negative, entitled, and naive tone on the whole article: >>> to which no real improvements are being made for some reason. (Incompetence? Politics? Both? Who knows.) The author is not acknowledging that some of his points were not addressed because of reasons other than incompetence and/or politics. I imagine this statement could offend some of the smart and hard-working people who are working on improving the python language. Reasons the author does not acknowledge: - the community does not agree with the author's subjective idea of what Python should look like - the solutions to a problem (I'm thinking GIL) come with a lot of consequences which are not readily acceptable - solving some of the issues would exacerbate backwards compatibility. This would increase the author's problems even more, because, as he states "This is particularly a pain for libraries where I expect to pip install them and have them "Just Work"."

darkf 10y ago
>However, many are subjective preferences Certainly, it is titled "Problems I Have" for a reason. :-) I do not expect everyone to agree with me, but it is what I feel I personally lack when using it quite a lot. > I imagine this statement could offend some of the smart and hard-working people who are working on improving the python language. That was certainly not my intention -- as stated, I do love the language and appreciate all work going into it. I do not intend to undermine their efforts, just point out some of my perceived design flaws. >- the community does not agree with the author's subjective idea of what Python should look like I think we all agree there should be a good solution to concurrency (and "stackless" variants which power eventlet, etc. have been used for ages; as has Twisted, of which asyncio is not a sufficient clone.), parallelism, etc. The standard library in general encourages use of higher-order functions and concepts borrowed primarily from FPLs (see: comprehensions, map/reduce, sort, etc.) I could not imagine seeing them backtracking on this -- it only helps them to go further in that direction. >- the solutions to a problem (I'm thinking GIL) come with a lot of consequences which are not readily acceptable I did not propose a solution because there are many, as you note; there are, however, implementations with decent solutions like AFAIK Jython. >- solving some of the issues would exacerbate backwards compatibility. Such as what?
- jsmeaton 10y ago
  > with decent solutions like AFAIK Jython. >>- solving some of the issues would exacerbate backwards compatibility. Such as what? Jython can't load native C extensions which should be GIL aware. Most programs, and the python interpreter itself, aren't thread safe so suddenly removing the GIL would break a lot of programs. I agree with you that the concurrency story for python sucks, but claiming solutions could exist without breaking back-compat is just not right.
  - al2o3cr 10y ago
    FWIW, the folks working on TruffleRuby have done some amazing things on this front - essentially making an interpreter for Ruby C extensions that JITs to code that's more-or-less identical in performance to the original native version.
  - darkf 10y ago
    >but claiming solutions could exist without breaking back-compat is just not right. I mean, you have a good point on C extensions but code relying on them (without a really portable API) is almost never going to be forward compatible anyway. (There are still quite a few C extensions not up to CPython 3 yet.)
  - Chris2048 10y ago
    Is Jython good though? Last I used it is had issues keeping pace, i.e. demonstrable memory issue that took a long time to fix, lagged considerably behind python 2/3 versions. It's also worth noting, that as an essentially transcompiled language, you need to have a good appreciation of Java machinery, in which case languages like Groovy provide good competition.
    - vorg 10y ago
      When talking about JVM languages suitable for building systems, Jython isn't generally mentioned for the reasons you give, nor is Apache Groovy. Those two are good for scripting, e.g. testing Java classes, build scripts, glue code. Besides Java, languages like Clojure, Scala, and Kotlin are usually considered as systems languages on the JVM.
SeanDav 10y ago
> "- solving some of the issues would exacerbate backwards compatibility." That boat sailed a long time ago with the introduction of Python 3. (Ok, Ok my comment is slightly tongue-in-cheek. I agree that backwards compatibility is usually a good idea and should not be broken without a great deal of thought.)
semi-extrinsic 10y ago
Another big issue to keep in mind when critiquing Python, as opposed to e.g. JavaScript or Ruby, is that Python is used for so much more besides webdev/etc. stuff. So making changes that improve life for webdevs could suddenly make life worse for people using Python in high energy physics, or in chemical engineering, or in AI research, or a large number of other fields that a webdev might not even know exists. Every supercomputer on the planet runs Python code, scientific Python usage is a really big field, with enough passionate users to hold multiple conferences every year; orders of magnitude more in casual users.
- bsg75 10y ago
  I would propose there are plenty of better solutions for webdev than Python, and that Pythons should remain focused on where it has been successful.
  - bsg75 10y ago
    Apparently people disagree with this sentiment. Allow me to expand on it: TL;DR - One language for all purposes is the wrong focus. - Python's success is largely due to things it has done well: Numeric and scientific computing (NumPy, SciPy), system administration scripting (yum, RHEL), workflow management (Luigi, Airflow, Snakemake). - The idea that one language can be used in all tiers leads to things like JavaScript. Does all things but none of them well. - PHP and Ruby are already strong in the webdev area, and there is little need for Python to compete here. Resources spent on making Python a top tier webdev language will always be a game of catch up, and distract from its strengths. - Yes Django is a thing, and should continue to evolve, but its unlikely to catch up to PHP.
dkersten 10y ago
the solutions to a problem (I'm thinking GIL) come with a lot of consequences which are not readily acceptable Are not readily acceptable to Guido. Whether that's a good thing (for the language) or not is subjective. At least Guido has a vision and is sticking to it!

by koliber 10y ago

darkf 10y ago

>However, many are subjective preferences Certainly, it is titled "Problems I Have" for a reason. :-) I do not expect everyone to agree with me, but it is what I feel I personally lack when using it quite a lot. > I imagine this statement could offend some of the smart and hard-working people who are working on improving the python language. That was certainly not my intention -- as stated, I do love the language and appreciate all work going into it. I do not intend to undermine their efforts, just point out some of my perceived design flaws. >- the community does not agree with the author's subjective idea of what Python should look like I think we all agree there should be a good solution to concurrency (and "stackless" variants which power eventlet, etc. have been used for ages; as has Twisted, of which asyncio is not a sufficient clone.), parallelism, etc. The standard library in general encourages use of higher-order functions and concepts borrowed primarily from FPLs (see: comprehensions, map/reduce, sort, etc.) I could not imagine seeing them backtracking on this -- it only helps them to go further in that direction. >- the solutions to a problem (I'm thinking GIL) come with a lot of consequences which are not readily acceptable I did not propose a solution because there are many, as you note; there are, however, implementations with decent solutions like AFAIK Jython. >- solving some of the issues would exacerbate backwards compatibility. Such as what?

jsmeaton 10y ago
> with decent solutions like AFAIK Jython. >>- solving some of the issues would exacerbate backwards compatibility. Such as what? Jython can't load native C extensions which should be GIL aware. Most programs, and the python interpreter itself, aren't thread safe so suddenly removing the GIL would break a lot of programs. I agree with you that the concurrency story for python sucks, but claiming solutions could exist without breaking back-compat is just not right.
- al2o3cr 10y ago
  FWIW, the folks working on TruffleRuby have done some amazing things on this front - essentially making an interpreter for Ruby C extensions that JITs to code that's more-or-less identical in performance to the original native version.
- darkf 10y ago
  >but claiming solutions could exist without breaking back-compat is just not right. I mean, you have a good point on C extensions but code relying on them (without a really portable API) is almost never going to be forward compatible anyway. (There are still quite a few C extensions not up to CPython 3 yet.)
- Chris2048 10y ago
  Is Jython good though? Last I used it is had issues keeping pace, i.e. demonstrable memory issue that took a long time to fix, lagged considerably behind python 2/3 versions. It's also worth noting, that as an essentially transcompiled language, you need to have a good appreciation of Java machinery, in which case languages like Groovy provide good competition.
  - vorg 10y ago
    When talking about JVM languages suitable for building systems, Jython isn't generally mentioned for the reasons you give, nor is Apache Groovy. Those two are good for scripting, e.g. testing Java classes, build scripts, glue code. Besides Java, languages like Clojure, Scala, and Kotlin are usually considered as systems languages on the JVM.

SeanDav 10y ago

> "- solving some of the issues would exacerbate backwards compatibility." That boat sailed a long time ago with the introduction of Python 3. (Ok, Ok my comment is slightly tongue-in-cheek. I agree that backwards compatibility is usually a good idea and should not be broken without a great deal of thought.)

semi-extrinsic 10y ago

Another big issue to keep in mind when critiquing Python, as opposed to e.g. JavaScript or Ruby, is that Python is used for so much more besides webdev/etc. stuff. So making changes that improve life for webdevs could suddenly make life worse for people using Python in high energy physics, or in chemical engineering, or in AI research, or a large number of other fields that a webdev might not even know exists. Every supercomputer on the planet runs Python code, scientific Python usage is a really big field, with enough passionate users to hold multiple conferences every year; orders of magnitude more in casual users.

bsg75 10y ago
I would propose there are plenty of better solutions for webdev than Python, and that Pythons should remain focused on where it has been successful.
- bsg75 10y ago
  Apparently people disagree with this sentiment. Allow me to expand on it: TL;DR - One language for all purposes is the wrong focus. - Python's success is largely due to things it has done well: Numeric and scientific computing (NumPy, SciPy), system administration scripting (yum, RHEL), workflow management (Luigi, Airflow, Snakemake). - The idea that one language can be used in all tiers leads to things like JavaScript. Does all things but none of them well. - PHP and Ruby are already strong in the webdev area, and there is little need for Python to compete here. Resources spent on making Python a top tier webdev language will always be a game of catch up, and distract from its strengths. - Yes Django is a thing, and should continue to evolve, but its unlikely to catch up to PHP.

dkersten 10y ago

the solutions to a problem (I'm thinking GIL) come with a lot of consequences which are not readily acceptable Are not readily acceptable to Guido. Whether that's a good thing (for the language) or not is subjective. At least Guido has a vision and is sticking to it!