Remove support for Python 2

odlgroup / odl

Operator Discretization Library https://odlgroup.github.io/odl/

Mozilla Public License 2.0

372 stars 105 forks source link

Remove support for Python 2 #1555

Open kohr-h opened 4 years ago

kohr-h commented 4 years ago

Since Python 2 has reached EOL it's time to remove support.

Code changes:

[ ] Remove __future__ and future imports
[ ] Remove dependency on future
[ ] Remove explicit subclassing of object
[ ] Find and remove explicit special-casing of Py2 (getargspec, setup.cfg deps, ...)
[ ] Travis test cases & config
[ ] Remove coding=utf-8 marks

Other:

[ ] Write up last commit that supports Py2 and document a way to install it
[ ] Make Python 3.5 minimum required (Reasons: @ syntax, faster lru_cache)

Edits:

Travis added
New min Python version added
UTF8 added

adler-j commented 4 years ago

Good overview. I think we'll also need to remove the python2 travis testing.

aringh commented 4 years ago

Write up last commit that supports Py2 and document a way to install it

A though related to this: wouldn't it be nicer to make a last release where Python 2 is supported, and then remove the support? In that way, it will be very clear which is the last commit that supports it, and how to install it.

I know we talked about making the next release "1.0", but it is over one and a half year since last relase, and still quite some things on the TODO-list for a "1.0" version.

kohr-h commented 4 years ago

last release where Python 2 is supported

I hoped nobody would bring this up :sweat_smile: Deep down I know you're right, but I just don't want to do it..

But seriously, I see (at least) two options:

Make something like a 0.9.9 release as the last to support Py2. For 1.0 I indeed feel that some big things are still on the table.
Abandon the semantic versioning scheme and use e.g. a release date based scheme like 2020.4. That would help remove the reluctance to make a less-than-perfect 1.0 release.

Let's be honest: there will be bugs and big (breaking?) changes even after 1.0, and currently I feel that this 1.0 release is just a huge hurdle for nothing. The year.month thing would be more rolling-release style where it's okay to "release at somewhat arbitrary time points". And it would make it more obvious (and potentially embarrassing) how long it's been since the last release.

aringh commented 4 years ago

It was an 0.9.9-typ relase I was thinking about - if we really want an "almost perfect" 1.0 release, we definitely have some more things we need to consider and do before that.

Regarding the semantics of release names: for me it does not really matter if we keep the current one or if we change to a year.month style. If the latter removes pressure when it comes to making new releases that only contain "moderate amount of patches and changes", then I think it sounds great! And yes, I think you are right about "breaking changes after 1.0": as long as the odl is maintained, there will inevitably be breaking changes when some new features or other ideas of how to do things comes around.