7 ms·

The current CPython maintainers believe that a JIT would be far too much complexity to maintain, and would drive away new contributors. I don't agree with their

The current CPython maintainers believe that a JIT would be far too much complexity to maintain, and would drive away new contributors. I don't agree with their analysis; I would argue the bigger thing driving new contributors away is them actively doing so. People show up all the time with basic patches for things other language runtimes have been doing for 20+ years and get roasted alive for daring to suggest something as arcane as method dispatch caches. The horror! This cements the CPython team as sort of a known "don't waste your time there" in PL research communities, distancing themselves from the people most likely and willing to help maintain their runtime.

ctoth 5y ago
So glad somebody finally said this. I've noticed this dynamic for years and it really is sad to watch. I remember reading over the community reviewing a large patchset someone had contributed a couple months ago and the amount of negativity was remarkable.
- hadcomplained 5y ago
  Would you mind telling me exactly which patchset you are referring to?
  - wswope 5y ago
    Not OP but probably this one: https://news.ycombinator.com/item?id=28896367 https://news.ycombinator.com/item?id=28896367.
- staticassertion 5y ago
  I had one conversation with Guido at Dropbox where I wanted to get a dependency updated so that I could write quickcheck tests. It was like pulling teeth - he didn't know what property testing was ("some haskell thing?" - his words) and so he wouldn't update it ("are you implying that how Dropbox writes tests today isn't good enough?" - his words), so I couldn't write generated tests. Sort of ironically, property testing was used elsewhere in the company to great success, and in fact we were all told the scary story of the 1 hour where empty passwords let anyone log into any account - a bug that a proeprty test is very well designed for. I walked away pretty embarrassed for him and decided I wasn't interested in further interaction.
  - jslaby 5y ago
    Isn't it really a "haskell thing", though? Generated testing of properties seems a bit overkill, but I might be mistaken about how that actually works.
    - staticassertion 5y ago
      quickcheck was initially a haskell project, but it's a little absurd to reduce proeprty testing down like that. I also wouldn't call it overkill. It's trivial to do generated tests.
xpressvideoz 5y ago
Python has always been adversarial to the PL communities, as seen in Guido's decision to limit the usefulness of the lambda function. He just didn't like the concept of long anonymous functions. I guess it is the inevitable characteristic of the typical "non-academic" languages, because I've also faced similar atmosphere in PHP and JavaScript too.
- Jasper_ 5y ago
  Language design is a different field and specialty than implementation. Whether lambdas are multi-line or not has no bearing on the compilers and VM runtime specialists I know who tell others to stay away. Maybe the language designers feel similarly about the direction of Python, I don't know, but that's a separate community I have much less insight into.
- Mawr 5y ago
  > He just didn't like the concept of long anonymous functions. And rightfully so. If a function is long enough to need multiple lines, it's also long enough to be named. Complaints about this seem to come from the functional language circles, where chaining 10 .filter()'s, .map()'s, etc. together in a single line is considered not only normal, but desirable and idiomatic. Why bother naming the intermediate results, right? The ability to stuff a million operations on a single line that, for whatever reason, seems so coveted by many is quite clearly one of the least important aspects of language design. Vertical space is cheap and plentiful. Human brain capacity is tiny. Therefore, optimize for readability not clever one-liners. This is the big benefit of a BDFL, having single a person with good taste be able to veto bad ideas. Guido, for the most part, has good taste so Python's ended up quite well designed.
  - toqy 5y ago
    I don’t think it’s a strong argument coming from a language that will happily allow some gnarly nested list comprehensions
  - School-Cotton 5y ago
    > If a function is long enough to need multiple lines, it's also long enough to be named. As a user of other languages, but only occasionally of Python, this type of reasoning (arbitrary limits because we think if you exceed them you’re probably structuring your code wrong) is totally alien to me. Why should the language have opinions about how I should or shouldn’t structure my code? Imagine if Rust or C++ had an arbitrary rule that you couldn’t have more than 10 functions in a class/impl; maybe it’d usually be correct style but people would still think the language making it a hard restriction was ridiculous.
edgyquant 5y ago
But a JIT is already planned for a future release it’s just there’s a ton of other improvements they can do to speed it up first. See: https://github.com/markshannon/faster-cpython/blob/master/plan.md https://github.com/markshannon/faster-cpython/blob/master/pl... where the plan is detailed. This is by a core python dev who is currently employed by Microsoft to enact this plan.
- Jasper_ 5y ago
  It's possible things are changing. I just remember things like this, which was extremely frustrating at the time: https://lwn.net/Articles/754163 https://lwn.net/Articles/754163 . Guido got visibly upset for this talk. In the last roughly 10 years, Google, Instagram, Dropbox, Facebook, and reddit all invested a lot of time into trying to make Python fast and was pushed away with harsh no's. There are dozens of forks and branches with basic optimizations that were rejected. I wish everyone the best of luck. But there's a side of me that's disappointed since this somewhat shows that it's only when these ideas come from inside the core maintainer team that they get acceptance. That's going to make it difficult to grow the team in the future.
  - oblvious-earth 5y ago
    > In the last roughly 10 years, Google, Instagram, Dropbox, Facebook, and reddit all invested a lot of time into trying to make Python fast and was pushed away with harsh no's. There are dozens of forks and branches with basic optimizations that were rejected. Is that true? The talk you link was about a very secretive fork of Python that Instagram was very adamant about not open sourcing until very recently (in fact it's not clear that what's open sourced is their full project). Other than that until recently all I've ever seen is either breaking the C-API or no clear commitment from the maintainers that this was a sustained effort to support and not just a drive-by complicated patch. In more recent times we have cinder, pyjion, pyston, and others. And CPython Devs are up-streaming either their work or their general approach.
    - hitekker 5y ago
oblvious-earth 5y ago
The winds are probably changing with the CPython maintainers. I expect in the next few versions the efforts of PyJion and Faster Cpython will add a JIT API to plug in your own JIT in to CPython.

ctoth 5y ago

So glad somebody finally said this. I've noticed this dynamic for years and it really is sad to watch. I remember reading over the community reviewing a large patchset someone had contributed a couple months ago and the amount of negativity was remarkable.

hadcomplained 5y ago
Would you mind telling me exactly which patchset you are referring to?
- wswope 5y ago
  Not OP but probably this one: https://news.ycombinator.com/item?id=28896367 https://news.ycombinator.com/item?id=28896367.
staticassertion 5y ago
I had one conversation with Guido at Dropbox where I wanted to get a dependency updated so that I could write quickcheck tests. It was like pulling teeth - he didn't know what property testing was ("some haskell thing?" - his words) and so he wouldn't update it ("are you implying that how Dropbox writes tests today isn't good enough?" - his words), so I couldn't write generated tests. Sort of ironically, property testing was used elsewhere in the company to great success, and in fact we were all told the scary story of the 1 hour where empty passwords let anyone log into any account - a bug that a proeprty test is very well designed for. I walked away pretty embarrassed for him and decided I wasn't interested in further interaction.
- jslaby 5y ago
  Isn't it really a "haskell thing", though? Generated testing of properties seems a bit overkill, but I might be mistaken about how that actually works.
  - staticassertion 5y ago
    quickcheck was initially a haskell project, but it's a little absurd to reduce proeprty testing down like that. I also wouldn't call it overkill. It's trivial to do generated tests.

xpressvideoz 5y ago

Python has always been adversarial to the PL communities, as seen in Guido's decision to limit the usefulness of the lambda function. He just didn't like the concept of long anonymous functions. I guess it is the inevitable characteristic of the typical "non-academic" languages, because I've also faced similar atmosphere in PHP and JavaScript too.

Jasper_ 5y ago
Language design is a different field and specialty than implementation. Whether lambdas are multi-line or not has no bearing on the compilers and VM runtime specialists I know who tell others to stay away. Maybe the language designers feel similarly about the direction of Python, I don't know, but that's a separate community I have much less insight into.
Mawr 5y ago
> He just didn't like the concept of long anonymous functions. And rightfully so. If a function is long enough to need multiple lines, it's also long enough to be named. Complaints about this seem to come from the functional language circles, where chaining 10 .filter()'s, .map()'s, etc. together in a single line is considered not only normal, but desirable and idiomatic. Why bother naming the intermediate results, right? The ability to stuff a million operations on a single line that, for whatever reason, seems so coveted by many is quite clearly one of the least important aspects of language design. Vertical space is cheap and plentiful. Human brain capacity is tiny. Therefore, optimize for readability not clever one-liners. This is the big benefit of a BDFL, having single a person with good taste be able to veto bad ideas. Guido, for the most part, has good taste so Python's ended up quite well designed.
- toqy 5y ago
  I don’t think it’s a strong argument coming from a language that will happily allow some gnarly nested list comprehensions
- School-Cotton 5y ago
  > If a function is long enough to need multiple lines, it's also long enough to be named. As a user of other languages, but only occasionally of Python, this type of reasoning (arbitrary limits because we think if you exceed them you’re probably structuring your code wrong) is totally alien to me. Why should the language have opinions about how I should or shouldn’t structure my code? Imagine if Rust or C++ had an arbitrary rule that you couldn’t have more than 10 functions in a class/impl; maybe it’d usually be correct style but people would still think the language making it a hard restriction was ridiculous.

edgyquant 5y ago

But a JIT is already planned for a future release it’s just there’s a ton of other improvements they can do to speed it up first. See: https://github.com/markshannon/faster-cpython/blob/master/plan.md https://github.com/markshannon/faster-cpython/blob/master/pl... where the plan is detailed. This is by a core python dev who is currently employed by Microsoft to enact this plan.

Jasper_ 5y ago
It's possible things are changing. I just remember things like this, which was extremely frustrating at the time: https://lwn.net/Articles/754163 https://lwn.net/Articles/754163 . Guido got visibly upset for this talk. In the last roughly 10 years, Google, Instagram, Dropbox, Facebook, and reddit all invested a lot of time into trying to make Python fast and was pushed away with harsh no's. There are dozens of forks and branches with basic optimizations that were rejected. I wish everyone the best of luck. But there's a side of me that's disappointed since this somewhat shows that it's only when these ideas come from inside the core maintainer team that they get acceptance. That's going to make it difficult to grow the team in the future.
- oblvious-earth 5y ago
  > In the last roughly 10 years, Google, Instagram, Dropbox, Facebook, and reddit all invested a lot of time into trying to make Python fast and was pushed away with harsh no's. There are dozens of forks and branches with basic optimizations that were rejected. Is that true? The talk you link was about a very secretive fork of Python that Instagram was very adamant about not open sourcing until very recently (in fact it's not clear that what's open sourced is their full project). Other than that until recently all I've ever seen is either breaking the C-API or no clear commitment from the maintainers that this was a sustained effort to support and not just a drive-by complicated patch. In more recent times we have cinder, pyjion, pyston, and others. And CPython Devs are up-streaming either their work or their general approach.
  - hitekker 5y ago

oblvious-earth 5y ago

The winds are probably changing with the CPython maintainers. I expect in the next few versions the efforts of PyJion and Faster Cpython will add a JIT API to plug in your own JIT in to CPython.