Hacker News Reader

Comment by Animats | Hacker News Reader

"I think one of the reasons Pypy isn't more popular is because its C interoperability story is weaker than the reference Python implementation"

The CPython crowd apparently made some change between CPython 3.4 and CPython 3.5 which changed how Windows DLLs are called. This broke Py2exe, which no longer works for the current release of CPython. [1]

CPython's approach to C extensions usually requires having the same Microsoft C compiler version used to build Python. This is now a problem for Python 2.7, because the Microsoft compiler version used to build it is no longer available. Microsoft recently changed their API for the C runtime, and CPython has been changed accordingly.

CPython's "C interoperability story" isn't really that good on Windows.

[1] http://stevedower.id.au/blog/building-for-python-3-5/

View on HN

> This is now a problem for Python 2.7, because the Microsoft compiler version used to build it is no longer available.

There is a CMake build system for 2.7 that works great with VS2013-2015:

https://github.com/python-cmake-buildsystem/python-cmake-bui...

The issue w/ MSVC is not that specific to CPython. It is generally quite hard to write libraries which use multiple C runtimes (Windows or not -- it just happens to be much more common on Windows than on Unix). I would be actually very surprised if that problem did not exist with any other language that distribute binaries.

Note that the problem you mentioned w/ python 2.7 is gone: MS has made a .msi available free of charge to build C extensions for 2.7, indefinitely (thanks to Steve Dower): https://www.microsoft.com/en-gb/download/details.aspx?id=442...

It's good enough for practical purposes - sure, you have to build a separate version of your package for every different version of VC++ that is used by your supported versions of Python, but we're still talking about 3-4 binaries top.

When that is not enough, you can still recompile manually if need be, so long as source for the module is available (which it is in most cases).

On the other hand, native modules are such a big part of the Python ecosystem, that not supporting the API and ABI at all confines any alternative implementations to a very small niche.

This is true on other OSes as well. C extensions are assumed to be compiled with the same compiler as Python itself. If you use distutils it will also use the same flags.

This is less problematic on other OSes where GCC dominates and clang is compatible, but it can bite on HPC systems that use PGI compilers.

Reply on news.ycombinator.com