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

"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

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)

Those people were not being paid to speed up CPython, though, but mostly-source-compatible (but not at all native extension compatible) alternative interpreters.

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.

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.

>That's absolutely not the case with IronPython, where being tied to the .NET ecosystem was very much the point.

That might very well be, but I talked about UnladdedSwallow and such "native" attempts.

Not attempts to port to a different ecosystem like Jython or IronPython or the js port.

>maintaining support for native extensions while speeding up the implementation would have been a goal even if it had to be in a fork.

That's not a necessary goal. One could very well want to improve CPython, the core, even if it meant breaking native extensions. Especially if doing so meant even more capabilities for optimization.

I, for one, would be fine with that, and am pretty sure all important native extensions would have adapted quite soon - like they adapted to Python 3 or the ARM M1 Macs.

In fact, one part of the current proposed improvements includes some (albeit trivial) fixes to native extensions.

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

Too bad .net is designed for windows and on linux the APIs feel like windows API that kinda sorta work on linux.

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

Core team wasn't friendly to breaking C API.

Current changes don't really break it.

Neither of those projects were ever going to be accepted upstream though.

My hope was that iron pythonreplaced cpython as the standard but for a number of reasons that was never to be.

Was the project run by a team based in Africa or Europe?

I don't know! [Whoosh]