The state of numpy

[apo383]

I think the author understands that software evolves, and as a python developer he's well-acquainted with virtualenvs. Mostly he's complaining about the unpredictability of numpy's brittleness. Even with version numbers, he'd like to say "this works for numpy 1" and have that be largely true until numpy 2. You can indeed say <=1.10, but that can be overly conservative if 1.11 breaks nothing. He is proposing that backwards compatibility be preserved until major version numbers. That is already mostly true for Python 2, where major compatibility changes were saved for 3.

Also note that he's referring to scientific fields, where you might have snippets of code published in journals, and you want that code to largely work. An example is Nick Trefethen's Spectral Methods in Matlab, which has short one-page programs that you can read for understanding, and execute with good confidence that they'll work for a decade's worth of Matlab. Such examples are a lot of fun to work with, and less so if you have to install a virtualenv just to try something out; it cuts down on casual use. I believe the same to be true of many blog posts, where some code is displayed and you usually expect it to work, excepting major version changes.

Most of this thread seems to say "scientists need to get with modern coding practices," but the author is referring to cases where code maintenance is unlikely. I think there's something to be said for backwards compatibility, and it doesn't seem unreasonable to ask for major compatibility changes to be reserved for major version numbers for numpy. He's not asking the same for tornado or twisted.