Repository: mne-tools/mne-python

Issue:
Python 2 support roadmap
What's the roadmap towards sunsetting Python 2 support for MNE? Many projects have already decided to support only Python 3, with one final Python 2 release that won't get any new features. MNE should be on the http://python3statement.org/ website, which means that we will have to drop Python 2 support by 2020 at the latest. Many projects will do or have done this earlier by releasing one final Python 2-compatible version, while development continues with Python 3-only code.


Discussion:
My vote is to follow NumPy and SciPy:

https://docs.scipy.org/doc/numpy-1.14.0/neps/dropping-python2.7-proposal.html

But for use our maintenance releases don't last nearly as long as theirs. So the important thing is that we drop new features at the end of 2018, which means 0.17 would probably be the last 2.7 release.
>My vote is to follow NumPy and SciPy

Yeah, why not?
no objection but I am generally in favor of not dropping support for
something if it does not cause major extra maintenance cost.

Here I just see that it makes our tests longer...

I like the idea of following NumPy. Should we prepare a short statement for the website? Should we also try to get on the Python 3 Statement website?

@agramfort it's nice that we currently support the two versions, but at least for me it is sometimes annoying/frustrating to keep stumbling over Python 2 incompatibilities (related to e.g. encoding or float/int). Even more so, we can't use some nice Python 3 features and have to carry around the six package to maintain Python 2 compatibility. I think discarding all that will free our resources for getting more important things done. The whole CI suite is already taking a long time, so dropping all Python 2 jobs will be a welcome relief for me (and Travis).

The other question is: does everything work with Python 3? I remember some people mentioning a while ago that mayavi is still in beta for Python 3, but this seems to be resolved.

How is this going to work technically? After we make the last Python 2 release (presumably 0.17), do we actively start to make the code more Python 3 like, or do we not touch it and just ensure that new features make use of Python 3? I'm assuming the latter, and the former only if someone has time to do it.
if for my next MNE training course all students have a working python 3 env
I am happy to make this decision rapidly.

we should ask on the mailing list if there is any objection too.

I think this should be possible since installing Python 3 via Anaconda is not more difficult than installing Python 2 :smile:. I'll ask on the mailing list.
We probably want to hear more MNE devs here. @kingjr in particular :)
Yes, more input would be great. I've already sent out a message to the mailing list.
How s mayavi on python 3 ?

On Wednesday, 2 May 2018, Clemens Brunner <notifications@github.com> wrote:

> Yes, more input would be great. I've already sent out a message to the
> mailing list (although with the wrong email address so this message is
> awaiting moderator approval).
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/mne-tools/mne-python/issues/5167#issuecomment-385951138>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AEp7DHN-G4a7qx94IW1GZ1-HotYZQZsrks5tuZ0CgaJpZM4TlHJ8>
> .
>

@larsoner claims if you use the environment.yml to set up your system, it works. Haven't tried it myself, but if Eric says so ...
Also https://github.com/enthought/mayavi/issues/84 is closed, so I'm assuming that it works (but haven't tried it either).
For almost 7 months our CIs have been running Py3k with Mayavi.
Do they include Mac and windows environments ?

On Wednesday, 2 May 2018, Eric Larson <notifications@github.com> wrote:

> For almost 7 months our CIs have been running Py3k with Mayavi.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/mne-tools/mne-python/issues/5167#issuecomment-385953542>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AEp7DKoKKGWAGEvY9dOcVu0hTfqvvB4Tks5tuZ93gaJpZM4TlHJ8>
> .
>

Yes
Ideally the dependencies would be available as official release rather than special github branch installations... Hopefully that will be the case soon...
I'm also all for dropping explicit Python 2 support once all the dependencies have official Py3-compatible releases and don't require any extra steps to install from a development branch. 

How dependent is the overall codebase on `six` for dual compatibility? My own experience is that well-written code, even string code, generally works well[1] on 2.7 and 3 without any changes except a `from __future__ import print_function, division` (at least for code that's not dependent on features introduced in a later Py3 point release like the new format strings). If that's the case, then we can leave that line in, even after we drop official Py2 support / CI testing and let limited, unsupported Py2 compatibility continue until too much of the code has Python 3 idioms.

[1] This of course ignores some memory optimality for some iterator methods.
We use `six` for a bunch of things, like `next`, `StringIO`, `BytesIO`, `string_types`, etc.
@palday which dependencies do not have official Python 3 support? AFAIK all packages in `environment.yml` are officially on PyPI, so it might not be necessary to pull them from specific branches.
I didn't have anything in particular in mind and I haven't looked at the Install page in a while, but I was thinking about how there used to be some special casing for Python 3, which I think is what @christianbrodbeck was also getting at.  My statement was more "conditional" and less "temporal".
Sure, we should check. What I meant to say though was that we have these special installs even for Python 2, so this is not a Python 3 issue. Of course we could check if the normal versions work in case no one has done that in a while. @larsoner @christianbrodbeck?
There are no special installs for Python 2, you can install everything you need with `conda install -c conda-forge mne` and that is what I still suggest to end users because it's the simplest for users hat don't want to get technical with Python before even starting...
The docs recommend using `pip` (via [environment.yml](https://raw.githubusercontent.com/mne-tools/mne-python/master/environment.yml)) to install MNE and not conda-forge, and everything seems to work with Python 3.
Now that mayavi is pip-installable on Python 3, I think we can safely implement the Python 3 transition following the example of NumPy. I can write a short text, but where should this text go? It could be a short section in README.rst and/or a short section in the documentation section of the website (e.g. in "Getting started" right after "Introduction to Python"). Let me know what you prefer. I will then also try to add MNE to https://python3statement.org/.
I would do the README plus `whats_new.rst` API section, plus maybe a `.. note` in `install_mne_python.rst`. That way the plan will be made clear to people when we release 0.17. It's a bit redundant but we do want to warn people they need to transition before 0.18.

Resolving patch:
diff --git a/doc/conf.py b/doc/conf.py
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -20,6 +20,7 @@
 import sphinx_gallery  # noqa
 import sphinx_bootstrap_theme
 from numpydoc import numpydoc, docscrape  # noqa
+import sphinx_fontawesome
 import mne
 
 # If extensions (or modules to document with autodoc) are in another directory,
@@ -53,6 +54,7 @@
     'sphinx.ext.mathjax',
     'sphinx.ext.todo',
     'sphinx_gallery.gen_gallery',
+    'sphinx_fontawesome',
     'numpydoc',
     'gen_commands',
 ]


Test patch: