Plan for dropping Python 2.7

[wholmgren]

The Python Software Foundation is dropping Python 2.7 support in 1.5 years (Jan 1, 2020) (ref). The major scientific python packages (numpy, pandas, matplotlib, scipy, etc.) are dropping Python 2.7 support in less than a year, though this is a little nuanced and depends on the package (ref).

The question here is should we commit to a plan for dropping Python 3 support, or should we wait until it's unavoidable?

Here's a list of pros and cons that I see for moving pvlib to python 3 only and a date for dropping python 3 support. This is specific to pvlib and python 3, rather than python 3 overall...

Pros:

• We can advertise pvlib on https://python3statement.org/
• Remove a small amount of compatibility code
• keyword only arguments could be useful for some complicated pvlib function signatures
• Matrix multiplication operator (3.5+)
• Better unpacking (useful for kwargs magic) (3.5+)
• We can (maybe) use f-strings in pvlib (3.6+)
• dict retains ordering, so no need to use OrderedDict in pvlib (3.6+)
• Maybe type annotations (3.7+) but I think the scientific python community is going to have to struggle with this for a bit

Cons:

• It's an unnecessary burden for people that are tied to 2.7

Proposed dates:

• 2019-06-01 (@wholmgren)

I think these pros are small but meaningful, especially once we can commit to 3.6+, while the cons are unknown because I don't have a good understanding of how many pvlib users are on 2.7 and what might be holding them back. My understanding is that download statistics from pypi and anaconda are not very reliable for this question, but I will still try to compile some soon.

Again, this is a discussion about pvlib moving to python 3 only -- it is not a discussion about the merits of python 3 overall. For example, while the new Python 3.7 breakpoint function looks great, it's not going to be used within pvlib so it's irrelevant to the discussion.

Anyone watching that is tied to 2.7 should speak now, because I think there are a handful of contributors that would like to push us to python 3 only sooner than later!

So, please post a date you'd like to see pvlib commit to Python 3+ only and list any additional pros and cons. I will update the lists as people post.

[markcampanelli]

It might be easiest to follow (and refer to) this plan: https://docs.scipy.org/doc/numpy/neps/dropping-python2.7-proposal.html

[AndyMender]

Though not a part of the project, as a user I would highly recommend dropping Python 2.7 support. Python 3 carries a huge number of improvements, especially starting from version 3.5 when full argument unpacking was introduced.

[uvchik]

As anybody is free to fork this project to something like pvlibpy2 it is still possible for the python2 community to keep the version alive and fix bugs. But I do not know any python2 user anymore.

Another question is the roadmap of python3 support. In our project we are discussing to drop python 3.4 support soon now python 3.7 is released. So soon we might be able to add the first python 3.5 features. We do not support python2 but this does not mean that we are ready for python 3.6 features.

[cedricleroy]

We (SunPower) are using both Python 2 and 3, but for the biggest part, we are still heavily tied to Python 2. The reason is that we have big and old code base which is still running Python 2, and have many dependencies between libraries / applications. Moving everything to Python 3 is on everyone mind, but not officially in the road-map yet.

I think the initiative is fair, and the timeline is long enough. It is a necessary evil, and will bring an additional argument for us to switch entirely to Python 3. Worst case, as @uvchik mentioned, we could fork the latest Python 2 compatible version, even though parallel forks is not really ideal.

[wholmgren]

Thanks for all the input so far. I’d like to avoid maintaining a “bug fix” branch and I’d like to avoid forks through 2019. I don’t think the python 3 benefits outweigh the costs associated with those options on that timescale.

[uvchik]

Maybe my statement was unclear.

1. I do not think that the developer should maintain a second fork, this fork has be maintained by those who need it.

2. I do not like the idea of a Py2-fork but it can be a sheet anchor for those who do not manage to switch in time and need to fix a bug. Otherwise they can just use the last supported version.

3. It will be more difficult for the pvlib to support Py2 in the future as scipy and pandas release the last Py2 version in December 2018. This will not take effect on the pvlib directly, so I think the pvlib is free to stretch the Py2 time. Therefore, the date suggested by @wholmgren seems just fine.

[mikofski]

@thunderfish24 the proposal link seemed broken, but this works:
https://github.com/numpy/numpy/blob/master/doc/neps/nep-0014-dropping-python2.7-proposal.rst

@wholmgren I like your proposal, and the timeline seems fine. I don't want to get into a debate over the merits of Python-3, to me it's just important to prepare to make the switch sooner rather than later because support for Python-2 will be more difficult approaching 2020.

[wholmgren]

It sounds like there is consensus around 2019-06-01. Perhaps some would prefer sooner and some later, but no one has said "this is too soon/late". Any last minute objections?

Moving on to how to do this. I suggest:

First, modify README.md. Something like:

pvlib-python is compatible with Python versions 2.7 and 3.4-3.7. Python 2.7 support will end on 2019-06-01.

Also add a note to the 0.6.0 whatsnew file.

Then, sign the python3statement.org by submitting a one line pull request to https://github.com/python3statement/python3statement.github.io/pulls

[wholmgren]

PR made to python3statement here: python3statement/python3statement.github.io#144

[wholmgren]

pvlib-python is now on https://python3statement.org/

[mikofski]

Thanks Will!!! But why can't we have a cool logo too