7 ms·

Python is in a situation where it is enormously popular, due to a winning aesthetic in syntax/ergonomics that appeals to both newbies and experienced programmer

Python is in a situation where it is enormously popular, due to a winning aesthetic in syntax/ergonomics that appeals to both newbies and experienced programmers. And due to this success, there is a lot of demand and interest in speeding the language up and getting rid of the GIL. But paradoxically, this veneer of simplicity hides an incredible amount of complexity. You have to read hundreds of lines of CPython to understand the full semantics of a statement like "a + b". The semantics are complicated/compromised by many optimizations and implementation details of CPython. This is a fantastic talk that goes into these details: https://youtu.be/qCGofLIzX6g https://youtu.be/qCGofLIzX6g It is not good for anybody that the semantics are this quirky. But it's especially not good for people trying to optimize the language, who basically have to implement quirk-for-quirk identical semantics to what CPython has ended up with after 30 years of evolution and optimization. I wish Python 3.0 had included a more formalized and cleaned up set of semantics. These things can't be simplified without a breaking change to the language (even if only a small number of programs truly depend on these quirks). I would say Python should fix this in 4.0, but the 2->3 transition was so painful and long that I'm not sure the ecosystem can take it.

marmaduke 5y ago
Have you seen the Python docs which have pages on the execution model and data model, with notes in implementation details? https://docs.python.org/3/reference/executionmodel.html https://docs.python.org/3/reference/executionmodel.html https://docs.python.org/3/reference/datamodel.html https://docs.python.org/3/reference/datamodel.html
- haberman 5y ago
  In your second link it says: > For instance, to evaluate the expression x + y, where x is an instance of a class that has an __add__() method, x.__add__(y) is called. The talk I linked to (https://youtu.be/qCGofLIzX6g https://youtu.be/qCGofLIzX6g) is a deep dive on how there is much more to the story than the simplified statement above. What I wish for is not better docs, but rather simpler language in which the statement above would actually be an accurate specification of the behavior implemented by the interpreter.
- ggrrhh_ta 5y ago
  I guess you are trying to imply that those documents cover a formal-enough description of what the execution and data model is. Well, even for the section "names" it just forgets to say if imported and non-imported names all share the same encoding and which should it be - just a nitpick, but with less than 5 seconds. Do you know that there are some behavioral limitations of dict that arise from a specific optimization in the implementation in C of dictionary iterators? If you create a new python following those documents, it is possible that you will allow a perfectly reasonable behavior that would fail in most other python interpreters.
  - joshuamorton 5y ago
    > Well, even for the section "names" it just forgets to say if imported and non-imported names all share the same encoding and which should it be - just a nitpick, but with less than 5 seconds https://www.python.org/dev/peps/pep-0263/ https://www.python.org/dev/peps/pep-0263/ Names aren't unique. > Do you know that there are some behavioral limitations of dict that arise from a specific optimization in the implementation in C of dictionary iterators? I'm rather curious what you're referring to here, do you mean dict-ordering, or something else?
    - ggrrhh_ta 5y ago
      Sorry, but "names aren't unique" does not even begin to define uniqueness - "from ... import X" imports and X; great; should it replace an "X" in a different encoding in the local namespace, or not? I can tell you it has to do with iterators, and maybe someone will comment on what that is.
      - joshuamorton 5y ago
        By names aren't unique, I mean with respect to "encoding", everything is the same. It seems like you're using "encoding" to mean something it doesn't? Do you just mean like "value"? > I can tell you it has to do with iterators, and maybe someone will comment on what that is. This sounds like you don't know what it is.
chrisseaton 5y ago
It wouldn't be too bad if it was complicated, but explicitly documented and tested. For example people joke about JavaScript comparison semantics posting things like this https://i.stack.imgur.com/35MpY.png https://i.stack.imgur.com/35MpY.png and laughing about it. But I wish Ruby and Python were this explicit and easy to understand!
- marmaduke 5y ago
  Python docs have pages on the execution model and data model, with notes in implementation details. What more do you want? https://docs.python.org/3/reference/executionmodel.html https://docs.python.org/3/reference/executionmodel.html https://docs.python.org/3/reference/datamodel.html https://docs.python.org/3/reference/datamodel.html Reading these documents is not hard, and it’s been an enormous help over the years for writing effective efficient Python.
  - chrisseaton 5y ago
    > What more do you want? Something formal, so I can actually reason about it and test it. These documents are just informal prose. Are they sound? I don't know. Do you? Does anyone? Does my implementation match what they say? Who knows. Does CPython even match it? Does anyone know?
    - aw1621107 5y ago
      Out of curiosity, how many languages would meet those criteria? Only one I can think of off the top of my head is CompCert's C dialect. Are there others?
      - chrisseaton 5y ago
        It's a spectrum - some languages do it a lot better than others. Not having anything more than a conversational English description of what it does is definitely the lower end of the spectrum. I'm sure very few are doing it perfectly, but for example Java has a formal semantics.
dec0dedab0de 5y ago
My gut instinct is that many of Python's quirks are the reason for it's popularity. Though I might not be understanding your suggestion. Could you give a specific example of something you would clean up if you were able to? I have the video in a tab but won't be able to watch until later.
- haberman 5y ago
  I think "a + b" is a good example. I really recommend the talk I linked (https://youtu.be/qCGofLIzX6g https://youtu.be/qCGofLIzX6g), it gets deep into this stuff. I don't think anyone benefits from "a + b" having so many special cases.
moonchrome 5y ago
Forget about language quirks, package management and version management in python is a nightmare. The ammount of time I wasted dealing with python environment related issues alone makes me avoid it if I can.

marmaduke 5y ago

Have you seen the Python docs which have pages on the execution model and data model, with notes in implementation details? https://docs.python.org/3/reference/executionmodel.html https://docs.python.org/3/reference/executionmodel.html https://docs.python.org/3/reference/datamodel.html https://docs.python.org/3/reference/datamodel.html

haberman 5y ago
In your second link it says: > For instance, to evaluate the expression x + y, where x is an instance of a class that has an __add__() method, x.__add__(y) is called. The talk I linked to (https://youtu.be/qCGofLIzX6g https://youtu.be/qCGofLIzX6g) is a deep dive on how there is much more to the story than the simplified statement above. What I wish for is not better docs, but rather simpler language in which the statement above would actually be an accurate specification of the behavior implemented by the interpreter.
ggrrhh_ta 5y ago
I guess you are trying to imply that those documents cover a formal-enough description of what the execution and data model is. Well, even for the section "names" it just forgets to say if imported and non-imported names all share the same encoding and which should it be - just a nitpick, but with less than 5 seconds. Do you know that there are some behavioral limitations of dict that arise from a specific optimization in the implementation in C of dictionary iterators? If you create a new python following those documents, it is possible that you will allow a perfectly reasonable behavior that would fail in most other python interpreters.
- joshuamorton 5y ago
  > Well, even for the section "names" it just forgets to say if imported and non-imported names all share the same encoding and which should it be - just a nitpick, but with less than 5 seconds https://www.python.org/dev/peps/pep-0263/ https://www.python.org/dev/peps/pep-0263/ Names aren't unique. > Do you know that there are some behavioral limitations of dict that arise from a specific optimization in the implementation in C of dictionary iterators? I'm rather curious what you're referring to here, do you mean dict-ordering, or something else?
  - ggrrhh_ta 5y ago
    Sorry, but "names aren't unique" does not even begin to define uniqueness - "from ... import X" imports and X; great; should it replace an "X" in a different encoding in the local namespace, or not? I can tell you it has to do with iterators, and maybe someone will comment on what that is.
    - joshuamorton 5y ago
      By names aren't unique, I mean with respect to "encoding", everything is the same. It seems like you're using "encoding" to mean something it doesn't? Do you just mean like "value"? > I can tell you it has to do with iterators, and maybe someone will comment on what that is. This sounds like you don't know what it is.

chrisseaton 5y ago

It wouldn't be too bad if it was complicated, but explicitly documented and tested. For example people joke about JavaScript comparison semantics posting things like this https://i.stack.imgur.com/35MpY.png https://i.stack.imgur.com/35MpY.png and laughing about it. But I wish Ruby and Python were this explicit and easy to understand!

marmaduke 5y ago
Python docs have pages on the execution model and data model, with notes in implementation details. What more do you want? https://docs.python.org/3/reference/executionmodel.html https://docs.python.org/3/reference/executionmodel.html https://docs.python.org/3/reference/datamodel.html https://docs.python.org/3/reference/datamodel.html Reading these documents is not hard, and it’s been an enormous help over the years for writing effective efficient Python.
- chrisseaton 5y ago
  > What more do you want? Something formal, so I can actually reason about it and test it. These documents are just informal prose. Are they sound? I don't know. Do you? Does anyone? Does my implementation match what they say? Who knows. Does CPython even match it? Does anyone know?
  - aw1621107 5y ago
    Out of curiosity, how many languages would meet those criteria? Only one I can think of off the top of my head is CompCert's C dialect. Are there others?
    - chrisseaton 5y ago
      It's a spectrum - some languages do it a lot better than others. Not having anything more than a conversational English description of what it does is definitely the lower end of the spectrum. I'm sure very few are doing it perfectly, but for example Java has a formal semantics.

dec0dedab0de 5y ago

My gut instinct is that many of Python's quirks are the reason for it's popularity. Though I might not be understanding your suggestion. Could you give a specific example of something you would clean up if you were able to? I have the video in a tab but won't be able to watch until later.

haberman 5y ago
I think "a + b" is a good example. I really recommend the talk I linked (https://youtu.be/qCGofLIzX6g https://youtu.be/qCGofLIzX6g), it gets deep into this stuff. I don't think anyone benefits from "a + b" having so many special cases.

moonchrome 5y ago

Forget about language quirks, package management and version management in python is a nightmare. The ammount of time I wasted dealing with python environment related issues alone makes me avoid it if I can.