Comment by jnxx | Hacker News Reader

Comment by jnxx | Hacker News Reader

The end-of-life of Python 2 will cause a lot of scientific software to break. Many readers who work in different domains of software development will just shrug and say "Then, Scientists should just change to Python 3 and write all new code in it".

It ain't that easy. The main issue is summarized in this tweet:

https://twitter.com/quantumpenguin/status/933123060822978560

In an attempt to summarize Hinsens argument:

Reproducibility is important for computational science. This means it needs to be possible to run the same code with the same data, and get the same result. And because code represents scientific models, not experiments, and these models are used for decades, reproducibility for decades is needed.

Yet Hinsen (who is a main contributor of both Numerical Python (numpy) and Scientific Python, observes that a typical Python script will only run two or three years, not five or more.

Further, Hinsen points out that scientific software consists of four layers: domain-specific code, domain-specific libraries, scientific infrastructure, and non-scientific infrastructure. While the scientific infrastructure code, for example Numerical Python or Pandas is already updated to use Python3, for many domain-specific libraries, this is not going to happen, because of restrictions on time and funding.

(An interesting insight for me: While by far most of the actual code in any given program will consist of OS routines, system libraries, and libraries such as Numpy, the total amount of scientific code outside of these layers is far larger, and will probably never be rewritten.)

There are two other interesting statements Hinsen has cited in other blog posts. One is Linus Torvalds ["We don't break user space"](https://lkml.org/lkml/2012/12/23/75).

The other is Rich Hicke's "Spec-ulation" keynote on maintaining compatibility of interfaces - here is an old HN thread: https://news.ycombinator.com/item?id=13085952

I understand a lot of the changes cause pain in the academic community. There's a lot that could be better. But I really don't agree with the reproducibility issues. Python 2 doesn't "disappear". It's still available. D.Beazley did an experiment of compiling old python versions recently and went back all the way to the pre-1.0, pre-vcs versions. They still compile (with minimal changes) and still run. Old packages are still available (you should keep copies of specific versions anyway if you want reproducibility). It's not trivial, but it's not rocket surgery either.

The article also seems to think other languages are somehow immune:

> Today’s Java implementations will run the very first Java code from 1995 without changes,

Even though Java release notes document incompatible changes: http://www.oracle.com/technetwork/java/javase/8-compatibilit...

I don’t understand what they mean with the Java comments. Moving from 5 to 6 was a massive pain at one of my companies. It was a two year transition that went into the EOL of 5. 6 to 7 was just barely any better. Maybe they wrote forward-compatible Java and never had that ugly experience. Given that python 3 has been on the radar for 10 years, they could have done the same for python.

Python has one backwards-incompatible change in 10 years, and I wouldn’t even call it a major one at the time. In these 10 years nobody who’s on these long-term projects and complaining on Twitter seems to have much as started testing on 3, let alone budgeted time or resources for a migration. Someone like Red Hat keeps coming to the rescue when the complaints get loud and extends the date by a few years — and rather than taking that as a clue that time is limited and to start working on a gentle, n-year upgrade plan, these groups just go back to acting like they have an infinite timeline. Until it happens all over again.

The good thing about linux’s backwards compatibility that they mention means that the python2 interpreter will probably be compilable long after its EOL.

It might compile, but with modern compilers doing increasingly aggressive optimizations (especially on undefined behaviour), it becomes more of a gamble whether the old source with a modern compiler produces the same results as the old code with an old compiler.

So use an old compiler?

If it doesn’t, the results from that computation are scientifically worthless. Reproducibility means more than just getting the same results from the same code with the same compiler (although that’s clearly a desirable prerequisite)

Seems like there are two different senses of "reproducibility" happening here:

* the developer variety: "running the same code produces a bitwise-identical result"

* the scientific variety: "repeating the experiment produces the same result"

The second one is much broader; a lot of the work in science is documenting what factors are relevant in "repeating" an experiment: a result which could only be obtained with one exact piece of apparatus would be dangerously close to being irreproducible. Similarly, the idea of "the same result" is subject to interpretation - for instance, measuring the muon lifetime by timing decays in a scintillator should produce a result close to the known value but it can't produce the same value every time since it's a fundamentally random process.

I remember reading Hinsen's blog post in 2017 when it made rounds in the scientific python community.

I think at universities and research facilities, there are many Python scripts that see few development, and with those, breaking changes are of course a problem, as the person who wrote them has potentially already left and unit tests are not common at all. So I understand his view, although I don't make it my own. I think they could get a long way by version pinning and using virtual environments.

I never experienced many problems with breaking changes in numpy and scipy, sometimes maybe with pandas. Writing and operating python based web services that heavily use the scientific python stack, I have hardly felt problems in terms of breaking changes, even though the code bases where considerable in size. I remember that binary compatibility of numpy had been an issue once, which we did resolve by linking against an older numpy version when building wheels, then running with more recent numpy versions.

Hinsen mainly thinks in terms of namespacing and maintaining backwards compatibility, yet I think this is a tough burden to impose upon the open source developers. What I would like is having each breaking change being announced in the latest patch release before the breaking change by a deprectaion warning that I can programmatically check for.

I enjoy Rich hickey's talks very much. His approach to versioning however I am careful about, when writing clojure code, I repeatedly stumbled over API "bugs" or irregularities, which were not fixed because they did not want to introduce a breaking change. In the end, this meant I lost much time writing my new code, because I thought I used a mature API and in fact it was sprinkled with immature functionality that just stayed there for the sake of backwards compatibility.

Reply on news.ycombinator.com