3 ms·
> * binary compatibility and testing are easy (I have a python binary module compiled on 32 bit ARM in 2014 that still loads without recompilation today) I'm c
by orf 8y ago
> * binary compatibility and testing are easy (I have a python binary module compiled on 32 bit ARM in 2014 that still loads without recompilation today)
I'm confused, are you trying to say a module compiled for Python 2.7 still works with Python 2.7?
- rogerbinns 8y agoI am saying exactly that. Note that it still works across compiler upgrades, libc updates, OS upgrades, python itself updates etc. By contrast if you compile a module against Python 3.4, it won't even work the same day against Python 3.5. ie the ever changing Python 3.x is more busy work than Python 2.7.
- orf 8y ago> I am saying exactly that. Note that it still works across compiler upgrades, libc updates, OS upgrades, python itself updates etc. Of course it does. Just like every other version? Compile something for Python X and it will continue working for Python X, where X is 2.7, 3.1, 3.4, etc etc. Overall your point seems to be very confused: Modules compiled for a Python version that has had no updates in 15 years still work, and this is somehow relevant to modules working across Python releases? You're comparing apples to oranges here I feel. > By contrast if you compile a module against Python 3.4, it won't even work the same day against Python 3.5. ie the ever changing Python 3.x is more busy work than Python 2.7. Sure, that's a different thing. That's across Python versions. As a counterpoint, Tensorflow built for Python 3.6 before 3.7 even began development runs just fine on 3.7. Of course the C-API evolves, and you'll have to adapt your C-API modules. As an example 3.6 made some changes[1]. 1. https://docs.python.org/3/whatsnew/3.6.html#build-and-c-api-changes https://docs.python.org/3/whatsnew/3.6.html#build-and-c-api-...