Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dropping Python 2 #2228

Open
megies opened this Issue Oct 5, 2018 · 10 comments

Comments

Projects
None yet
6 participants
@megies
Copy link
Member

megies commented Oct 5, 2018

This is just intended as a place to summarize any things to keep in mind once we drop Python 2.7.
Just add bullet points for any things that should be done after dropping Py2K, e.g. making use of Python 3 only features in code.

High Priority

  • bump major version to 2
  • drop basemap, full switch to cartopy
  • remove usages of the future package (see #1752 and #1613)
  • make sure docs discourage using pip < 9.0 or setuptools < 24.3
  • make sure docs discourage using the setup.py directly (favor using pip)
  • raise an informative exception if the user tries to import obspy > 2.0.0 on python 2 as recommended here
  • raise an informative exception if setup.py is run by python 2 as recommended here
  • replace usages of urllib with requests (see #1254)
  • add obspy to the python 3 statement timeline (see #1764)
  • ...

Low Priority

  • remove usages of the __future__ imports (perhaps only until pep 563 is applicable)
  • add type hints to public functions/methods (or use stub files?)
  • maybe can revert part of #2167? Mostly affects Py2 I think
  • use pathlib
  • ...

Handle some deprecations on 3.7

  • DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
@d-chambers

This comment has been minimized.

Copy link
Member

d-chambers commented Oct 5, 2018

Would it make sense for a major version bump after dropping 2.7?

@krischer

This comment has been minimized.

Copy link
Member

krischer commented Oct 5, 2018

Would it make sense for a major version bump after dropping 2.7?

Yes, I think we should do this. Seems to be how all the other big projects handle it as well.

In terms of actually doing it we could follow some form of this strategy: https://blog.jupyter.org/release-of-ipython-6-0-2068cfb2c2a

Probably on in light-version as might not have the manpower to do it at full scale.

@QuLogic

This comment has been minimized.

Copy link
Member

QuLogic commented Oct 6, 2018

I applied the changes that IPython did into Matplotlib; it is fairly straightforward and should be easy to do for ObsPy.

@d-chambers

This comment has been minimized.

Copy link
Member

d-chambers commented Oct 6, 2018

@QuLogic are you referring to the changes highlighted here: http://python3statement.org/practicalities/ ? I will add a few of these to @megies list.

@QuLogic

This comment has been minimized.

Copy link
Member

QuLogic commented Oct 6, 2018

Yep, basically those things.

@hugovk

This comment has been minimized.

Copy link

hugovk commented Oct 25, 2018

A handy tool called pyupgrade can help you upgrade syntax and remove some dead wood once you're ready:

pyupgrade `find . -name "*.py" -type f` --py3-plus

https://github.com/asottile/pyupgrade

@heavelock

This comment has been minimized.

Copy link
Contributor

heavelock commented Oct 29, 2018

How about dropping at the same time support for 3.4? Some of big projects such as Matplotlib drop its support along with 2.7.

@megies

This comment has been minimized.

Copy link
Member Author

megies commented Oct 30, 2018

How about dropping at the same time support for 3.4? Some of big projects such as Matplotlib drop its support along with 2.7.

Debian Jessie has LTS until June 2020 and has Python 3.4 so I would rather only drop Python 3.4 if there's a good reason.

@krischer

This comment has been minimized.

Copy link
Member

krischer commented Oct 30, 2018

Dropping 3.4 and jumping straight to 3.5 would enable us to use the typing module which would indeed be quite nice and give us a chance to clean up the documentation a lot. Also, the generalized unpacking in 3.5 is quite handy to have around.

But similar arguments can be made for some things in 3.6 so we have to make a cut somewhere.

My vote would go to jumping straight to 3.5 and possibly even to 3.6. Dropping Python 2 support will require a major version jump in any case and we can still bugfix the old version which will also keep running on all the LTS versions. I feel like most people these days install conda in any case so they are less dependent on system packages.

@megies

This comment has been minimized.

Copy link
Member Author

megies commented Oct 30, 2018

Well, in any case, with the current major release frequency or well.. period, rather.. of 1-2 years the discussion about py3.4 might be completely obsolete anyway, since it's gone for sure in 3 years.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.