Hacker News Reader

The problem with IronPython, and really most other alternative implementations of Python, is their inability to reuse native code packages, because CPython extension API is so low-level and tied to the VM's implementation details (and that cannot be easily changed now for backwards compatibility reasons). Such packages are fairly common, and if you take them all out, it significantly reduces the value of Python as an ecosystem.

View on HN

If you're using IronPython then you're probably just trying to embed a familiar scripting language into something, not trying to adopt the Python ecosystem.

Besides, while you lose out on Python's native ecosystem you gain access to all of .net's.

I'm not disputing that IronPython can be useful (although one also has to consider https://github.com/pythonnet/pythonnet, which wraps CPython into an IronPython-like projection). But if it can't share the library ecosystem, it might as well be a different language for all practical purposes. And it turned out that there aren't enough people who were interested in a Python/.NET combo for its own sake, so it remained niche. Any new implementation of Python on top of .NET VM would likely get similar reception for all the same reasons.

Reply on news.ycombinator.com