Re: Dropping support for 2.7 in 2020

I would drop 2.7 sooner. NumPy/SciPy dropping it is the absolute cutoff, but there’s no reason why we can’t jump the gun (and lead rather than follow). Py2.7 users can make do with older releases. As Stéfan mentioned, this is not about erasing Py2.7 support, but not releasing new features on Py2.7. Very different. I envision that we stop producing Py2.7 releases after 0.13, but we call that an “LTS” release which will get bugfix backports until 2020. imho, with Py3.4 and especially Py3.5, Py3-only suddenly became very attractive. My three favourite features are type annotations, keyword-only arguments (these two together make it much easier to produce correct code and debug), and the @ matrix multiplication operator. The latter makes linear algebra code *so* *much* nicer to read and write, and we have our fair share in scikit-image. For my own projects, I am now Py3.5-only, always. Finally, as others have mentioned, but is worth restating: - Conda allows user-space installs of Python versions and packages, so you don’t ever depend on your sysadmin-controlled environment. - It is *absolutely false* that conda packages are only useful on Windows — I have failed to compile scipy both on OSX and Ubuntu boxes. - It is also *not* a requirement to download the monolithic Anaconda distro — with miniconda (which should be the default), you just install precisely what you need. - With conda-forge we now have a community-run repository of binary conda packages. So, in short, the switch to Py3 is easier than ever for *all* users, some might just not realise it yet ;), and switching to a Py3-only programming environment is a boon to all the scikit-image devs… though again some might not realise it yet ;). Juan. On 21 May 2016 at 12:20:38 PM, Nathaniel Smith (njs@vorpus.org) wrote: On May 20, 2016 07:30, "Michael Sarahan" <msarahan@gmail.com> wrote:
I don't think this is a concern for cython or scikit-image, but many people at bumping into the language support limit in the C++11 sense with Python 2.7 on Windows. Since VS 2008 is the de-facto standard compiler for Python 2.7, people are unable to use C++11 code in modules for Python 2.7. Some people use newer compilers anyway, which sometimes works, but is mixing runtimes, and can lead to bugs or crashes. Many people would like to support Python 2.7 using a different compiler for the whole ecosystem. One example is Ilastik, by folks at HHMI, using VS 2012 to have a custom stack: https://github.com/ilastik/ilastik-build-conda
I think getting mingwpy finished and polished is probably an easier solution for this problem than forking the entire py27-on-windows ecosystem :-) -n -- You received this message because you are subscribed to the Google Groups "scikit-image" group. To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe@googlegroups.com. To post to this group, send email to scikit-image@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/scikit-image/CAPJVwB%3DjRQtHn9Xj0xwv3hxtDs.... For more options, visit https://groups.google.com/d/optout.

I'd like to revive this discussion with a bit of added context. We (principally people from IPython/Jupyter, Matplotlib, Sympy and Scikit-bio) are putting together a statement for Scientific Python community projects to signal that we're not planning to maintain Python 2 support forever. We're saying that we will end Python 2 support in or before 2020, to correspond with the end of support for Python 2.7 itself. http://python3statement.github.io/ The more projects that get on board with this, the better we can make the case that researchers and users need Python 3 to be available. Then we can all benefit from a reduced maintenance burden. So scikit-image wouldn't be making a lone stand on this - there are a number of projects already agreeing to drop Python 2 support by 2020, and we hope there will be more soon. Thanks, Thomas On Monday, 23 May 2016 04:30:21 UTC+1, Juan Nunez-Iglesias wrote:
I would drop 2.7 sooner. NumPy/SciPy dropping it is the absolute cutoff, but there’s no reason why we can’t jump the gun (and lead rather than follow). Py2.7 users can make do with older releases. As Stéfan mentioned, this is not about erasing Py2.7 support, but not releasing new features on Py2.7. Very different. I envision that we stop producing Py2.7 releases after 0.13, but we call that an “LTS” release which will get bugfix backports until 2020.
imho, with Py3.4 and especially Py3.5, Py3-only suddenly became very attractive. My three favourite features are type annotations, keyword-only arguments (these two together make it much easier to produce correct code and debug), and the @ matrix multiplication operator. The latter makes linear algebra code *so* *much* nicer to read and write, and we have our fair share in scikit-image. For my own projects, I am now Py3.5-only, always.
Finally, as others have mentioned, but is worth restating: - Conda allows user-space installs of Python versions and packages, so you don’t ever depend on your sysadmin-controlled environment. - It is *absolutely false* that conda packages are only useful on Windows — I have failed to compile scipy both on OSX and Ubuntu boxes. - It is also *not* a requirement to download the monolithic Anaconda distro — with miniconda (which should be the default), you just install precisely what you need. - With conda-forge we now have a community-run repository of binary conda packages.
So, in short, the switch to Py3 is easier than ever for *all* users, some might just not realise it yet ;), and switching to a Py3-only programming environment is a boon to all the scikit-image devs… though again some might not realise it yet ;).
Juan.
On 21 May 2016 at 12:20:38 PM, Nathaniel Smith (n...@vorpus.org <javascript:>) wrote:
I don't think this is a concern for cython or scikit-image, but many
On May 20, 2016 07:30, "Michael Sarahan" <msar...@gmail.com <javascript:>> wrote: people at bumping into the language support limit in the C++11 sense with Python 2.7 on Windows. Since VS 2008 is the de-facto standard compiler for Python 2.7, people are unable to use C++11 code in modules for Python 2.7. Some people use newer compilers anyway, which sometimes works, but is mixing runtimes, and can lead to bugs or crashes. Many people would like to support Python 2.7 using a different compiler for the whole ecosystem. One example is Ilastik, by folks at HHMI, using VS 2012 to have a custom stack: https://github.com/ilastik/ilastik-build-conda
I think getting mingwpy finished and polished is probably an easier solution for this problem than forking the entire py27-on-windows ecosystem :-)
-n -- You received this message because you are subscribed to the Google Groups "scikit-image" group. To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image...@googlegroups.com <javascript:>. To post to this group, send email to scikit...@googlegroups.com <javascript:>. To view this discussion on the web, visit https://groups.google.com/d/msgid/scikit-image/CAPJVwB%3DjRQtHn9Xj0xwv3hxtDs... <https://groups.google.com/d/msgid/scikit-image/CAPJVwB%3DjRQtHn9Xj0xwv3hxtDsjBvKYtJTB38ewBuZ84cNR4xw%40mail.gmail.com?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout.

Le 04/07/2016 à 11:38, Thomas Kluyver a écrit :
I'd like to revive this discussion with a bit of added context. We (principally people from IPython/Jupyter, Matplotlib, Sympy and Scikit-bio) are putting together a statement for Scientific Python community projects to signal that we're not planning to maintain Python 2 support forever. We're saying that we will end Python 2 support in or before 2020, to correspond with the end of support for Python 2.7 itself.
http://python3statement.github.io/
The more projects that get on board with this, the better we can make the case that researchers and users need Python 3 to be available. Then we can all benefit from a reduced maintenance burden. So scikit-image wouldn't be making a lone stand on this - there are a number of projects already agreeing to drop Python 2 support by 2020, and we hope there will be more soon.
Thanks for your note. Does it mean that all new version of those libraries will support python2.7 until 2020 or just that you can release a bugfix to already released version supporting 2.7? If it's the first option, it means we can't use python3 features before 2020 and we will be "in late" with these features.

On 4 July 2016 at 10:47, François Boulogne <fboulogne@sciunto.org> wrote:
Does it mean that all new version of those libraries will support python2.7 until 2020 or just that you can release a bugfix to already released version supporting 2.7?
If it's the first option, it means we can't use python3 features before 2020 and we will be "in late" with these features.
The statement doesn't commit projects to support 2.7 until any specific date - scikit-bio already went Python 3 only with its release last month, for instance. We're agreeing to end Python 2 support by 2020, but projects are welcome to do it earlier than that. For IPython, we're planning for the 6.0 feature release (some time in 2017) to be Python 3 only, while we'll make bugfix releases of the 5.x series for longer than normal to support users on Python 2.
participants (3)
-
François Boulogne
-
Juan Nunez-Iglesias
-
Thomas Kluyver