Update APE10 to have higher minimum python 3 versions - #25

I'm not sure if we ever made a decision on updating APEs, but I feel like this is a valid case

@astrofrog, @eteq - shall we merge this change in minimum python version addendum? I made the PR to implement removing python3.3 tests in master -- astropy/astropy#6021

Just a minor point: astropy 3.0 isn't a LTS and python 3.4 wouldn't reach end of life till 2019 (expected: 2019-03-16). So following the logic in the APE, including the new update, python 3.4 should be supported until astropy 3.2 or 3.3.

That doesn't mean I'm opposed to dropping python 3.4 support earlier - I'm definetly for it, there are a lot of amazing and handy new features in 3.5 and 3.6! It's just that nothing in the APE (including update) justifies that.

As v3.0 is already a python3 only version, we will have tons of code removal for it. If we refactor anyway, being able to use py3.5+ features would be really nice, and py3.7 will come out just before v3.1.

Can we do a new survey anytime soon to estimate how large percentage of our users use py3.4 as their main version?

I'd be happy to put up a poll on the FB group. I think there's enough people there to give a robust sampling. I'll discuss with folks today F2F at PyAstro17.

We can do a poll on twitter too with the following options:

Python 2.7
Python 3.0-3.2
Python 3.3-3.4
Python 3.5+

(since limited to 4 options)

As long as Python 2 is supported there is no real gain to drop support for Python 3.3 (except saving CI time), as it is not possible to use the new Python 3 features anyway. So for Astropy 2.0, even if there is no official support for Python 3.3, it should still be usable.

It will be more interesting for the following versions, when Python 2 is no more supported ! Dropping Python 3.4 for Astropy v3.0 seems reasonable, since this version is probably not widely used. I use py3.4 for our unit tests with the current Debian stable, but a new version of Debian should come in a few months with Python 3.5. And the latest Ubuntu LTS also comes with Python 3.5.

@saimn - The main argument for dropping py3.3 for v2.0 is that it will become unsupported during the lifetime of the release and thus we better don't say that we support it (while it may of course still work).

@bsipocz - Sure, and that's a good motivation.

As long as Python 2 is supported there is no real gain to drop support for Python 3.3 (except saving CI time), as it is not possible to use the new Python 3 features anyway.

That's not the whole motivation.

Python 2.7 still receives bugfixes, while 3.3 does not (except for security related ones, ordinary bugfixes have been stopped since March 9th, 2014 - more than 3 years ago!). So by dropping 3.3 we can remove workarounds for bugs fixed in 2.7 and 3.4+ but not in 3.3.

A poll sounds like a good idea: always good to have some real data!

Realized it was easier to just implement my comment, so all is good!

BTW Numpy 1.13 will support Python 2.7 and 3.4 - 3.6:
https://github.com/numpy/numpy/releases/tag/v1.13.0rc1

@saimn - just to be clear: are you happy with this given #25 (comment) / #25 (comment) ?

@eteq - Yes that's fine for me (sorry if my initial comment was not clear)

OK, great. @astrofrog, if this looks good to you, I think this is set to go.

It seems all of you approved the changes to APE10 - so, ready to merge!?

All good. Merging, and thanks @mhvk!