Konrad has been making that argument for a long time, and I don't know what the long term solution is. However, the use of Fortran as a benchmark of stability is a bit misleading. Fortran was undergoing rapid development in the years before Fortran 77, with Fortran II, DEC Fortran, and Rational Fortran being somewhat incompatible variations on the theme, and it was only with the standardization of the language that stability could be assumed. And if you wrote in a language that didn't survive the winnowing, Algol-68 for instance, you were in trouble. But even apart from from the languages, the hardware was changing, with different floating point formats on different hardware, so that prior to IEEE-754 the results of computations carried out on one machine were not always the same as results on another. Such differences still persist, with dependencies on math library and compiler versions, choice of rounding, and hardware, although with much reduced in effect. The C language is another example, the lack of a C99 standard, maintained compiler on Windows for Python 2.7 being one of the considerations in dropping support for Python 2. And let us not overlook C++, which, IMHO, has only reached its Fortran 77 equivalent with C++11.

I think the take away here is that we are still in the very early days of scientific computing with Python, it has really only been coming on strong for maybe five years. Those of us, including Konrad, who were early adopters scouting the terrain, were bound to end up with a few arrows in our back. Early adoption is always a gamble, with a tradeoff between the risk of choosing a language that mutates or dies, versus the payoff of using a language that blossoms and makes life easier. In my mind, Python 3.5 is the rough equivalent of Fortran 77, or maybe Fortran 95, and I don't know when the Python scientific stack will truly settle, but I expect it will be sometime in the next 5-10 years. At that point, we may want to look at having a "reference" version of NumPy, but I think it is still too early to make such a guarantee, although we do try to avoid being too disruptive while still making progress.

These considerations are probably cold comfort to folks like Konrad who have extensive code bases, some probably dating back to Numeric, that they need to maintain, but I do think things will get better.

<snip>

Chuck