4 ms·

Answer is very simple. Amount of people who got paid to make python fast was rounded to 0.

dekhn 4y ago
Not really. There were a couple engineers working at Google on a project called unladen swallow which was extremely promising but it eventually got canceled. The developer who worked at Microsoft to make iron python I think that was his full-time project as well and it was definitely faster than cpython at the time
- pstrateman 4y ago
  Neither of those projects were ever going to be accepted upstream though.
  - dekhn 4y ago
    My hope was that iron pythonreplaced cpython as the standard but for a number of reasons that was never to be.
- switch007 4y ago
  Was the project run by a team based in Africa or Europe?
  - dekhn 4y ago
    I don't know! [Whoosh]
- dragonwriter 4y ago
  Those people were not being paid to speed up CPython, though, but mostly-source-compatible (but not at all native extension compatible) alternative interpreters.
  - coldtea 4y ago
    That's because the core team wasn't friendly to them making changes in CPython. Not because they deliberately only wanted to build an alternative interpreter.
    - dragonwriter 4y ago
      That's absolutely not the case with IronPython, where being tied to the .NET ecosystem was very much the point. But if it was just core-team resistance and not a more fundamentally different objective than just improving the core interpreter performance, maintaining support for native extensions while speeding up the implementation would have been a goal even if it had to be in a fork. They were solving a fundamentally different (and less valuable to the community) problem than the new faster CPython project.
      - dekhn 4y ago
        If I remember correctly iron python ran on mono it just didn't have all of the .net bits. I remember at the python conference when it was introduced he actually showed how you could bring up clippy or a wizard programmatically from python talking directly to the operating system through its native apis. Really the value came from the thread safe container/collections data types which are the foundation of high performance programming
        LtWorf 4y ago
        Too bad .net is designed for windows and on linux the APIs feel like windows API that kinda sorta work on linux.
        dekhn 4y ago
        I've used a few .net applications on Linux and they work pretty well. But I've never actually tried to develop using mono. I really wish Microsoft had got all in on linux .net support 1 years ago
      - 4y ago
- tnvaught 4y ago
  "The developer who worked at Microsoft to make iron python" - Jim Hugunin [1] (say his name!) to whom much is owed by the python community and humanity, generally. [1] https://en.wikipedia.org/wiki/Jim_Hugunin https://en.wikipedia.org/wiki/Jim_Hugunin
  - dekhn 4y ago
    I'm sorry I had forgotten at the time. I almost got to work with him at Google. I agree he's a net positive for humanity (I used numeric heavily back in the day)

Not really. There were a couple engineers working at Google on a project called unladen swallow which was extremely promising but it eventually got canceled. The developer who worked at Microsoft to make iron python I think that was his full-time project as well and it was definitely faster than cpython at the time

pstrateman 4y ago
Neither of those projects were ever going to be accepted upstream though.
- dekhn 4y ago
  My hope was that iron pythonreplaced cpython as the standard but for a number of reasons that was never to be.
switch007 4y ago
Was the project run by a team based in Africa or Europe?
- dekhn 4y ago
  I don't know! [Whoosh]
dragonwriter 4y ago
Those people were not being paid to speed up CPython, though, but mostly-source-compatible (but not at all native extension compatible) alternative interpreters.
- coldtea 4y ago
  That's because the core team wasn't friendly to them making changes in CPython. Not because they deliberately only wanted to build an alternative interpreter.
  - dragonwriter 4y ago
    That's absolutely not the case with IronPython, where being tied to the .NET ecosystem was very much the point. But if it was just core-team resistance and not a more fundamentally different objective than just improving the core interpreter performance, maintaining support for native extensions while speeding up the implementation would have been a goal even if it had to be in a fork. They were solving a fundamentally different (and less valuable to the community) problem than the new faster CPython project.
    - dekhn 4y ago
      If I remember correctly iron python ran on mono it just didn't have all of the .net bits. I remember at the python conference when it was introduced he actually showed how you could bring up clippy or a wizard programmatically from python talking directly to the operating system through its native apis. Really the value came from the thread safe container/collections data types which are the foundation of high performance programming
      - LtWorf 4y ago
        Too bad .net is designed for windows and on linux the APIs feel like windows API that kinda sorta work on linux.
        dekhn 4y ago
        I've used a few .net applications on Linux and they work pretty well. But I've never actually tried to develop using mono. I really wish Microsoft had got all in on linux .net support 1 years ago
    - 4y ago
tnvaught 4y ago
"The developer who worked at Microsoft to make iron python" - Jim Hugunin [1] (say his name!) to whom much is owed by the python community and humanity, generally. [1] https://en.wikipedia.org/wiki/Jim_Hugunin https://en.wikipedia.org/wiki/Jim_Hugunin
- dekhn 4y ago
  I'm sorry I had forgotten at the time. I almost got to work with him at Google. I agree he's a net positive for humanity (I used numeric heavily back in the day)