4 ms·

> I suspect a lot of financial data code is going to break. Reminds me of when Numpy removed a lot of types like np.bool a few releases ago, because they were

> I suspect a lot of financial data code is going to break. Reminds me of when Numpy removed a lot of types like np.bool a few releases ago, because they were aliases of the standard library types. Which broke a ton of libraries having Numpy versions pinned to ">=1.0" or even worse, "~=1.0" expecting them to follow the standard practice of incrementing the major version when they break compatibility. It's not terrible because you just pin your project to 1.23 or whatever, but it was very annoying when everything I was using just started breaking. I wonder if Python plans to do the same with this - the 2 to 3 transition was painful and dragged on for a decade, nobody wants to do that again for 3 to 4. When they remove this function and break back compatibility with old code, is that going to happen in a future 3.x release?

hexane360 3y ago
It's worth noting that numpy and scipy have a consistent policy now, although it's not semver. Deprecations will always happen at least 2 minor versions before removal: https://numpy.org/neps/nep-0023-backwards-compatibility.html https://numpy.org/neps/nep-0023-backwards-compatibility.html https://numpy.org/doc/stable/dev/depending_on_numpy.html#runtime-dependency-version-ranges https://numpy.org/doc/stable/dev/depending_on_numpy.html#run... So, when using numpy in a package, and you've tested e.g. versions 1.12 to 1.22, you should require 'numpy>=1.12,<1.25', because something deprecated in version 1.23 could be removed in 1.25.
jkrejcha 3y ago
Yes, they're almost certainly going to do it a 3.x release. I think in some senses these backward compatibility breaks have already happened. I remember that Google got bit by async becoming a keyword in I think Tensorflow. Generally a lot of old Python 3 code still works today if it doesn't do anything really weird like that, but I do definitely think that the pain of Python 2 to 3 was painful so they don't really want to repeat it. I think it is probably prudent to treat point releases as major releases at least with regards to Python.

hexane360 3y ago

It's worth noting that numpy and scipy have a consistent policy now, although it's not semver. Deprecations will always happen at least 2 minor versions before removal: https://numpy.org/neps/nep-0023-backwards-compatibility.html https://numpy.org/neps/nep-0023-backwards-compatibility.html https://numpy.org/doc/stable/dev/depending_on_numpy.html#runtime-dependency-version-ranges https://numpy.org/doc/stable/dev/depending_on_numpy.html#run... So, when using numpy in a package, and you've tested e.g. versions 1.12 to 1.22, you should require 'numpy>=1.12,<1.25', because something deprecated in version 1.23 could be removed in 1.25.

jkrejcha 3y ago

Yes, they're almost certainly going to do it a 3.x release. I think in some senses these backward compatibility breaks have already happened. I remember that Google got bit by async becoming a keyword in I think Tensorflow. Generally a lot of old Python 3 code still works today if it doesn't do anything really weird like that, but I do definitely think that the pain of Python 2 to 3 was painful so they don't really want to repeat it. I think it is probably prudent to treat point releases as major releases at least with regards to Python.