Repository navigation
What to support for astropy 2.0? #6000
Description
In #5819, it seems python 3.3 is blocking what is at least a reasonable nice solution to a tricky problem (string truncation). This made me wonder about what we should support for astropy 2.0. My suggestion is to drop both python 3.3 and 3.4, as well as numpy 1.7 and 1.8 (both of which have quite a few exceptions).
If people agree, I'll turn this into a PR that makes those changes.
Reacted by Larry Bradley, P. L. Lim and Brigitta Sipőcz
Activity
demitri commentedon May 3, 2017
The 2.0 allows you to be more aggressive; I completely agree. I suspect that the majority of installations are still Python 2.x (based on nothing more than pure speculation), so I'd say that dropping support for 3.3 and 3.4 won't be terribly painful for users, but definitely beneficial for development.
astrofrog commentedon May 3, 2017
@mhvk - just to clarify, are you saying we would support 2.7, 3.5, 3.6? And do we actually need to drop 3.3 or would simply dropping numpy 1.7 and 1.8 be enough? Given our clear roadmap in https://github.com/astropy/astropy-APEs/blob/master/APE10.rst, I would be more in favor of dropping Numpy 1.7 and 1.8 if possible and avoid changing our plans for Python versions. In fact I think we should support the last 4 numpy versions (based on discussions in the past), and 1.12 is out so we should only be supporting Numpy 1.9+.
pllim commentedon May 3, 2017
Issue number 6000!
mhvk commentedon May 3, 2017
I should have looked at the road-map... Now doing that, I guess I would slightly change my suggestion to just up the python numbers by 0.1, i.e., support Python 2.7, and >=3.4 for 2.0, and support Python >=3.5 for astropy 3.0. The latter is especially relevant since it means we can finally start using
@; I also think it is reasonable: the switch to python 3 really started only in the last few years, so most people will have switched to Python 3.5 (first google item that backs this up: http://ianozsvald.com/2016/06/20/results-for-which-version-of-python-2vs3-do-london-data-scientists-use/)Somewhat relevant:
p.s. More generally, I'm a little confused why for LTS versions we aim to support so many different versions. I think because a LTS is long-lived, it is all the more reason to make that the time to narrow the set down.
EDIT: added EOL from https://docs.python.org/devguide/#status-of-python-branches following #6000 (comment)
mhvk commentedon May 3, 2017
On numpy it seems we did converge: remove 1.7 and 1.8 for 2.0, and almost certainly 1.9 for 3.0 (since numpy 1.13 is about to be released).
mhvk commentedon May 3, 2017
p.s. I'd up the python numbers for all in the APE, i.e., astropy 4.0 is at python >=3.6 -- lots of good class initialization stuff that allows us to remove many metaclasses, making the code substantially easier to understand.
MSeifert04 commentedon May 3, 2017
Python 3.3 has an expected "end of life" in september this year. So the question with 3.3 should rather be: Do we want to support it for 21 months (we support astropy 2.0 for 2 years) after it was officially marked "dead"?
Update APE10 to have higher minimum python 3 versions
mhvk commentedon May 3, 2017
@MSeifert04 - That certainly does it for me... I think that might in fact inform our logic more generally: we should only support versions that will be supported for most of any LTS's life span, which suggests we should not support 3.4 for astropy 3.0 either (I updated my table above).
I made a PR to the APE: astropy/astropy-APEs#25
mhvk commentedon May 31, 2017
Closing, since we decided on Python >=3.4, numpy >=1.9 for astropy 2.0.
saimn commentedon May 31, 2017
btw, is there any policy for scipy ? I was looking at
Sersic2Dwhich has a special treatment for scipy <= 0.11 (released in 2012 !).MSeifert04 commentedon May 31, 2017
@saimn Not that I know of. These special treatements are mostly added when someone files a bug report because a feature didn't work with his or her SciPy version.
But SciPy is really hard to build for windows if one doesn't use
anacondaor another package manager including pre-build binaries. So I wouldn't be surprised if there are at least a few people with really old SciPy versions around.saimn commentedon Jun 1, 2017
Ok, the number of workarounds for old Scipy versions seems to be very small, so probably not a big issue to keep these.
mhvk commentedon Jun 1, 2017
Well, scipy 0.11 doesn't even run on python3, so that one can be removed for astropy 3.0. More generally, I think it is good to state a version we aim to support or perhaps a general policy (similarly for hdf5, I guess).