dropping python 2.7 and numpy <1.13.3
Hi all, I've always had in mind that SciPy would follow NumPy in its timeline for dropping Python 2.7. However, as far as I can tell we've never had the discussion on this list. So here's the proposal: Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 onwards new releases will be Python 3 only, and the last release before that date will be an LTS release. That means SciPy 1.2.0 will be the LTS release, and 1.3.0 will be >= py3.5. Also, we haven't changed the minimum numpy version we support in quite a while, we're still at 1.8.2. And that will have to change anyway after dropping Python 2.7. The current minimum numpy versions we require are: - py27: 1.8.2 - py35: 1.9.3 - py36: 1.12.1 - py37: 1.13.1 We have always aimed to support at least 4 numpy versions (i.e. 2 year old versions). The differences per Python version in minimum numpy version are annoying (we don't consistently check that in our main __init__.py or in setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum required NumPy version to 1.13.3. That'll still be 4 supported releases, 1.13.3-1.16.x. Cheers, Ralf [1] http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html [2] NumPy thread on dropping py27: https://mail.python.org/pipermail/numpy-discussion/2017-November/077341.html
Hi,
Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 onwards new releases will be Python 3 only, and the last release before that date will be an LTS release. That means SciPy 1.2.0 will be the LTS release, and 1.3.0 will be >= py3.5.
+1 We should also think a bit about the timeline for cleanups and removals of py2/py3 workarounds. Maybe it's useful to postpone large-scale cleanups a bit. For example, how about we state that we allow new code to be py3-only, but we do not remove existing py2 constructs puntil scipy 1.14? Or for the duration of the LTS support. Also, we haven't changed the minimum numpy version we support in quite a
while, we're still at 1.8.2. And that will have to change anyway after dropping Python 2.7. The current minimum numpy versions we require are: - py27: 1.8.2 - py35: 1.9.3 - py36: 1.12.1 - py37: 1.13.1 We have always aimed to support at least 4 numpy versions (i.e. 2 year old versions). The differences per Python version in minimum numpy version are annoying (we don't consistently check that in our main __init__.py or in setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum required NumPy version to 1.13.3. That'll still be 4 supported releases, 1.13.3-1.16.x.
+1 in general. However numpy 1.13.0 has been released in July 2017, so it makes it less then two full years. I don't have a firm opinion on what is the optimum time from the last supported numpy version though. Cheers,
Ralf
[1] http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html [2] NumPy thread on dropping py27: https://mail.python.org/pipermail/numpy-discussion/2017-November/077341.html
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
Py 2.7 means more than just "Python2.7". We have tool chains for the various versions of Python, with (perhaps hidden) dependencies. In particular, I’m thinking of Python2.7 on Windows, which is built with MSVisualC++ v9. Since MSVC9 isn’t fully C99 compliant, SciPy has had to forgo many features of C99 to stay compatible, let alone C11 or C18. Perhaps now would be a good time to list our dependencies explicitly and think about the toolchain roadmap in general? BTW, Py3.5 and 3.6 are built with VisualC++ v14.0. See https://wiki.python.org/moin/WindowsCompilers#Which_Microsoft_Visual_C.2B-.2... <https://wiki.python.org/moin/WindowsCompilers#Which_Microsoft_Visual_C.2B-.2...> -Paul
On Nov 11, 2018, at 5:07 AM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
Hi,
Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 onwards new releases will be Python 3 only, and the last release before that date will be an LTS release. That means SciPy 1.2.0 will be the LTS release, and 1.3.0 will be >= py3.5.
+1
We should also think a bit about the timeline for cleanups and removals of py2/py3 workarounds. Maybe it's useful to postpone large-scale cleanups a bit. For example, how about we state that we allow new code to be py3-only, but we do not remove existing py2 constructs puntil scipy 1.14? Or for the duration of the LTS support.
Also, we haven't changed the minimum numpy version we support in quite a while, we're still at 1.8.2. And that will have to change anyway after dropping Python 2.7. The current minimum numpy versions we require are: - py27: 1.8.2 - py35: 1.9.3 - py36: 1.12.1 - py37: 1.13.1 We have always aimed to support at least 4 numpy versions (i.e. 2 year old versions). The differences per Python version in minimum numpy version are annoying (we don't consistently check that in our main __init__.py or in setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum required NumPy version to 1.13.3. That'll still be 4 supported releases, 1.13.3-1.16.x.
+1 in general.
However numpy 1.13.0 has been released in July 2017, so it makes it less then two full years. I don't have a firm opinion on what is the optimum time from the last supported numpy version though.
Cheers, Ralf
[1] http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html <http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html> [2] NumPy thread on dropping py27: https://mail.python.org/pipermail/numpy-discussion/2017-November/077341.html <https://mail.python.org/pipermail/numpy-discussion/2017-November/077341.html>
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org <mailto:SciPy-Dev@python.org> https://mail.python.org/mailman/listinfo/scipy-dev <https://mail.python.org/mailman/listinfo/scipy-dev> _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
On Sun, Nov 11, 2018 at 10:28 AM Paul van Mulbregt < p.vanmulbregt@comcast.net> wrote:
Py 2.7 means more than just "Python2.7". We have tool chains for the various versions of Python, with (perhaps hidden) dependencies. In particular, I’m thinking of Python2.7 on Windows, which is built with MSVisualC++ v9. Since MSVC9 isn’t fully C99 compliant, SciPy has had to forgo many features of C99 to stay compatible, let alone C11 or C18.
Yes, a more recent MSVC is an important benefit. We'll still have to deal with more minor non-C99-compliance on mor exotic platforms (AIX, Solaris, etc.) but that's less of a problem.
Perhaps now would be a good time to list our dependencies explicitly and think about the toolchain roadmap in general?
There's: - Cython: we always require a recent one, are about to bump to >0.28.5 or 0.29 - NumPy: proposed >1.13.3 - compilers: in general, whatever works for the Python versions we target. and we're accepting patches as needed for more exotic compilers supported by numpy.distutils(issue volume is very low). - LAPACK: >=3.4.1 - OpenBLAS: whichever recent version works (usually only 1-2 versions that are non-buggy enough). - Sphinx + numpydoc: whatever recent versions work. >= 1.6.6 for Sphinx and 0.8.0 for numpydoc I believe. - pytest/asv/wheel/multibuild: same, something recent. This is documented in various places, but usually not very complete or up-to-date unfortunately. Most of those dependencies are independent from each other. Cheers, Ralf
BTW, Py3.5 and 3.6 are built with VisualC++ v14.0. See
https://wiki.python.org/moin/WindowsCompilers#Which_Microsoft_Visual_C.2B-.2...
-Paul
On Nov 11, 2018, at 5:07 AM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
Hi,
Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 onwards new releases will be Python 3 only, and the last release before that date will be an LTS release. That means SciPy 1.2.0 will be the LTS release, and 1.3.0 will be >= py3.5.
+1
We should also think a bit about the timeline for cleanups and removals of py2/py3 workarounds. Maybe it's useful to postpone large-scale cleanups a bit. For example, how about we state that we allow new code to be py3-only, but we do not remove existing py2 constructs puntil scipy 1.14? Or for the duration of the LTS support.
Also, we haven't changed the minimum numpy version we support in quite a
while, we're still at 1.8.2. And that will have to change anyway after dropping Python 2.7. The current minimum numpy versions we require are: - py27: 1.8.2 - py35: 1.9.3 - py36: 1.12.1 - py37: 1.13.1 We have always aimed to support at least 4 numpy versions (i.e. 2 year old versions). The differences per Python version in minimum numpy version are annoying (we don't consistently check that in our main __init__.py or in setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum required NumPy version to 1.13.3. That'll still be 4 supported releases, 1.13.3-1.16.x.
+1 in general.
However numpy 1.13.0 has been released in July 2017, so it makes it less then two full years. I don't have a firm opinion on what is the optimum time from the last supported numpy version though.
Cheers,
Ralf
[1] http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html [2] NumPy thread on dropping py27: https://mail.python.org/pipermail/numpy-discussion/2017-November/077341.html
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
Just read the NumPy discussion thread. Some suggestions in that thread: 1. Bump the major version number after the LTS release. 2. Allow cleaning up of the code after the LTS release to take advantage of the newly allowed features. Counter suggestion: Don't clean up the code, in either the py3 codebase or the LTS release. That would make it easier to back-port PRs as needed. I didn’t see mention one way or the other in https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-propo... <https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-propo...> Did NumPy come to a decision on these? SciPy doesn't appear to be a signatory to http://www.python3statement.org/ <http://www.python3statement.org/> Should it be? -Paul
On Nov 11, 2018, at 2:51 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Nov 11, 2018 at 10:28 AM Paul van Mulbregt <p.vanmulbregt@comcast.net <mailto:p.vanmulbregt@comcast.net>> wrote: Py 2.7 means more than just "Python2.7". We have tool chains for the various versions of Python, with (perhaps hidden) dependencies. In particular, I’m thinking of Python2.7 on Windows, which is built with MSVisualC++ v9. Since MSVC9 isn’t fully C99 compliant, SciPy has had to forgo many features of C99 to stay compatible, let alone C11 or C18.
Yes, a more recent MSVC is an important benefit. We'll still have to deal with more minor non-C99-compliance on mor exotic platforms (AIX, Solaris, etc.) but that's less of a problem.
Perhaps now would be a good time to list our dependencies explicitly and think about the toolchain roadmap in general?
There's: - Cython: we always require a recent one, are about to bump to >0.28.5 or 0.29 - NumPy: proposed >1.13.3 - compilers: in general, whatever works for the Python versions we target. and we're accepting patches as needed for more exotic compilers supported by numpy.distutils(issue volume is very low). - LAPACK: >=3.4.1 - OpenBLAS: whichever recent version works (usually only 1-2 versions that are non-buggy enough). - Sphinx + numpydoc: whatever recent versions work. >= 1.6.6 for Sphinx and 0.8.0 for numpydoc I believe. - pytest/asv/wheel/multibuild: same, something recent.
This is documented in various places, but usually not very complete or up-to-date unfortunately. Most of those dependencies are independent from each other.
Cheers, Ralf
BTW, Py3.5 and 3.6 are built with VisualC++ v14.0. See https://wiki.python.org/moin/WindowsCompilers#Which_Microsoft_Visual_C.2B-.2... <https://wiki.python.org/moin/WindowsCompilers#Which_Microsoft_Visual_C.2B-.2...>
-Paul
On Nov 11, 2018, at 5:07 AM, Evgeni Burovski <evgeny.burovskiy@gmail.com <mailto:evgeny.burovskiy@gmail.com>> wrote:
Hi,
Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 onwards new releases will be Python 3 only, and the last release before that date will be an LTS release. That means SciPy 1.2.0 will be the LTS release, and 1.3.0 will be >= py3.5.
+1
We should also think a bit about the timeline for cleanups and removals of py2/py3 workarounds. Maybe it's useful to postpone large-scale cleanups a bit. For example, how about we state that we allow new code to be py3-only, but we do not remove existing py2 constructs puntil scipy 1.14? Or for the duration of the LTS support.
Also, we haven't changed the minimum numpy version we support in quite a while, we're still at 1.8.2. And that will have to change anyway after dropping Python 2.7. The current minimum numpy versions we require are: - py27: 1.8.2 - py35: 1.9.3 - py36: 1.12.1 - py37: 1.13.1 We have always aimed to support at least 4 numpy versions (i.e. 2 year old versions). The differences per Python version in minimum numpy version are annoying (we don't consistently check that in our main __init__.py or in setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum required NumPy version to 1.13.3. That'll still be 4 supported releases, 1.13.3-1.16.x.
+1 in general.
However numpy 1.13.0 has been released in July 2017, so it makes it less then two full years. I don't have a firm opinion on what is the optimum time from the last supported numpy version though.
Cheers, Ralf
[1] http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html <http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html> [2] NumPy thread on dropping py27: https://mail.python.org/pipermail/numpy-discussion/2017-November/077341.html <https://mail.python.org/pipermail/numpy-discussion/2017-November/077341.html>
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org <mailto:SciPy-Dev@python.org> https://mail.python.org/mailman/listinfo/scipy-dev <https://mail.python.org/mailman/listinfo/scipy-dev> _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org <mailto:SciPy-Dev@python.org> https://mail.python.org/mailman/listinfo/scipy-dev <https://mail.python.org/mailman/listinfo/scipy-dev>
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org <mailto:SciPy-Dev@python.org> https://mail.python.org/mailman/listinfo/scipy-dev <https://mail.python.org/mailman/listinfo/scipy-dev> _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org <mailto:SciPy-Dev@python.org> https://mail.python.org/mailman/listinfo/scipy-dev <https://mail.python.org/mailman/listinfo/scipy-dev>
SciPy doesn't appear to be a signatory to http://www.python3statement.org/ Should it be?
IMO yes, instructions are here: https://github.com/python3statement/python3statement.github.io On Mon, Nov 12, 2018 at 7:40 PM Paul van Mulbregt <p.vanmulbregt@comcast.net> wrote:
Just read the NumPy discussion thread. Some suggestions in that thread: 1. Bump the major version number after the LTS release. 2. Allow cleaning up of the code after the LTS release to take advantage of the newly allowed features. Counter suggestion: Don't clean up the code, in either the py3 codebase or the LTS release. That would make it easier to back-port PRs as needed.
I didn’t see mention one way or the other in https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-propo... Did NumPy come to a decision on these?
SciPy doesn't appear to be a signatory to http://www.python3statement.org/ Should it be?
-Paul
On Nov 11, 2018, at 2:51 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Nov 11, 2018 at 10:28 AM Paul van Mulbregt < p.vanmulbregt@comcast.net> wrote:
Py 2.7 means more than just "Python2.7". We have tool chains for the various versions of Python, with (perhaps hidden) dependencies. In particular, I’m thinking of Python2.7 on Windows, which is built with MSVisualC++ v9. Since MSVC9 isn’t fully C99 compliant, SciPy has had to forgo many features of C99 to stay compatible, let alone C11 or C18.
Yes, a more recent MSVC is an important benefit. We'll still have to deal with more minor non-C99-compliance on mor exotic platforms (AIX, Solaris, etc.) but that's less of a problem.
Perhaps now would be a good time to list our dependencies explicitly and think about the toolchain roadmap in general?
There's: - Cython: we always require a recent one, are about to bump to >0.28.5 or 0.29 - NumPy: proposed >1.13.3 - compilers: in general, whatever works for the Python versions we target. and we're accepting patches as needed for more exotic compilers supported by numpy.distutils(issue volume is very low). - LAPACK: >=3.4.1 - OpenBLAS: whichever recent version works (usually only 1-2 versions that are non-buggy enough). - Sphinx + numpydoc: whatever recent versions work. >= 1.6.6 for Sphinx and 0.8.0 for numpydoc I believe. - pytest/asv/wheel/multibuild: same, something recent.
This is documented in various places, but usually not very complete or up-to-date unfortunately. Most of those dependencies are independent from each other.
Cheers, Ralf
BTW, Py3.5 and 3.6 are built with VisualC++ v14.0. See
https://wiki.python.org/moin/WindowsCompilers#Which_Microsoft_Visual_C.2B-.2...
-Paul
On Nov 11, 2018, at 5:07 AM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
Hi,
Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 onwards new releases will be Python 3 only, and the last release before that date will be an LTS release. That means SciPy 1.2.0 will be the LTS release, and 1.3.0 will be >= py3.5.
+1
We should also think a bit about the timeline for cleanups and removals of py2/py3 workarounds. Maybe it's useful to postpone large-scale cleanups a bit. For example, how about we state that we allow new code to be py3-only, but we do not remove existing py2 constructs puntil scipy 1.14? Or for the duration of the LTS support.
Also, we haven't changed the minimum numpy version we support in quite a
while, we're still at 1.8.2. And that will have to change anyway after dropping Python 2.7. The current minimum numpy versions we require are: - py27: 1.8.2 - py35: 1.9.3 - py36: 1.12.1 - py37: 1.13.1 We have always aimed to support at least 4 numpy versions (i.e. 2 year old versions). The differences per Python version in minimum numpy version are annoying (we don't consistently check that in our main __init__.py or in setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum required NumPy version to 1.13.3. That'll still be 4 supported releases, 1.13.3-1.16.x.
+1 in general.
However numpy 1.13.0 has been released in July 2017, so it makes it less then two full years. I don't have a firm opinion on what is the optimum time from the last supported numpy version though.
Cheers,
Ralf
[1] http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html [2] NumPy thread on dropping py27: https://mail.python.org/pipermail/numpy-discussion/2017-November/077341.html
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
-- Mark Mikofski, PhD (2005) *Fiat Lux*
On Mon, Nov 12, 2018 at 8:00 PM Mark Alexander Mikofski < mikofski@berkeley.edu> wrote:
SciPy doesn't appear to be a signatory to http://www.python3statement.org/ Should it be?
IMO yes, instructions are here: https://github.com/python3statement/python3statement.github.io
Yes, if the proposal is accepted, then we should add ourselves there. It seems that the proposal is uncontroversial. I propose to accept it if no significant objections have been made in 3 days (so 1 week after the start of this thread).
On Mon, Nov 12, 2018 at 7:40 PM Paul van Mulbregt < p.vanmulbregt@comcast.net> wrote:
Just read the NumPy discussion thread. Some suggestions in that thread: 1. Bump the major version number after the LTS release. 2. Allow cleaning up of the code after the LTS release to take advantage of the newly allowed features. Counter suggestion: Don't clean up the code, in either the py3 codebase or the LTS release. That would make it easier to back-port PRs as needed.
For now I'd suggest no cleanups - backports will be needed for a while.
I didn’t see mention one way or the other in https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-propo... Did NumPy come to a decision on these?
No hard decision IIRC, but leaning towards no cleanups. Cheers, Ralf
On Wed, Nov 14, 2018 at 8:52 PM Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Mon, Nov 12, 2018 at 8:00 PM Mark Alexander Mikofski < mikofski@berkeley.edu> wrote:
SciPy doesn't appear to be a signatory to http://www.python3statement.org/ Should it be?
IMO yes, instructions are here: https://github.com/python3statement/python3statement.github.io
Yes, if the proposal is accepted, then we should add ourselves there.
It seems that the proposal is uncontroversial. I propose to accept it if no significant objections have been made in 3 days (so 1 week after the start of this thread).
Okay, looks like we agree on this! I'll send a doc PR for the release notes, as well as a PR to python3statement. Cheers, Ralf
On Mon, Nov 12, 2018 at 7:40 PM Paul van Mulbregt < p.vanmulbregt@comcast.net> wrote:
Just read the NumPy discussion thread. Some suggestions in that thread: 1. Bump the major version number after the LTS release. 2. Allow cleaning up of the code after the LTS release to take advantage of the newly allowed features. Counter suggestion: Don't clean up the code, in either the py3 codebase or the LTS release. That would make it easier to back-port PRs as needed.
For now I'd suggest no cleanups - backports will be needed for a while.
I didn’t see mention one way or the other in https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-propo... Did NumPy come to a decision on these?
No hard decision IIRC, but leaning towards no cleanups.
Cheers, Ralf
On Sat, 10 Nov 2018 19:22:33 -0800, Ralf Gommers wrote:
I've always had in mind that SciPy would follow NumPy in its timeline for dropping Python 2.7. However, as far as I can tell we've never had the discussion on this list. So here's the proposal: Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 onwards new releases will be Python 3 only, and the last release before that date will be an LTS release. That means SciPy 1.2.0 will be the LTS release, and 1.3.0 will be >= py3.5.
scikit-image made the same move at the end of May, and the only technical issue that arose was managing the large number of backports. For that, Matthias Bussonier's MeeSeeksDev bot has been invaluable (it automatically backports PRs on request, or by adding the issue to an appropriately tagged milestone).
setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum required NumPy version to 1.13.3. That'll still be 4 supported releases, 1.13.3-1.16.x.
+1; having per-Python-version NumPy dependencies is an unnecessary developer burden. Stéfan
On Mon, Nov 12, 2018 at 11:20 PM Stefan van der Walt <stefanv@berkeley.edu> wrote:
On Sat, 10 Nov 2018 19:22:33 -0800, Ralf Gommers wrote:
I've always had in mind that SciPy would follow NumPy in its timeline for dropping Python 2.7. However, as far as I can tell we've never had the discussion on this list. So here's the proposal: Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 onwards new releases will be Python 3 only, and the last release before that date will be an LTS release. That means SciPy 1.2.0 will be the LTS release, and 1.3.0 will be >= py3.5.
scikit-image made the same move at the end of May, and the only technical issue that arose was managing the large number of backports.
Thanks Stefan, good to know. For that, Matthias Bussonier's MeeSeeksDev bot has been invaluable (it
automatically backports PRs on request, or by adding the issue to an appropriately tagged milestone).
I'd suggest to wait with installing that until it's really clear we need it. So far, we haven't had a bot that wasn't more trouble than it's worth I think. Cheers, Ralf
setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum required NumPy version to 1.13.3. That'll still be 4 supported releases, 1.13.3-1.16.x.
+1; having per-Python-version NumPy dependencies is an unnecessary developer burden.
Stéfan _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
Hi, la, 2018-11-10 kello 19:22 -0800, Ralf Gommers kirjoitti:
I've always had in mind that SciPy would follow NumPy in its timeline for dropping Python 2.7. However, as far as I can tell we've never had the discussion on this list. So here's the proposal: Let's follow NumPy's timeline [1], which says that from 1 Jan 2019 onwards new releases will be Python 3 only, and the last release before that date will be an LTS release. That means SciPy 1.2.0 will be the LTS release, and 1.3.0 will be >= py3.5.
Following Numpy on the Py3 plan sounds good to me. On the cleaning up thing, it may indeed be best to avoid unnecessarily removing the Py2 workarounds, as the more the LTS branch diverges, the more work is required in backporting things to it. New code of course can follow Py3 only.
Also, we haven't changed the minimum numpy version we support in quite a while, we're still at 1.8.2. And that will have to change anyway after dropping Python 2.7. The current minimum numpy versions we require are: - py27: 1.8.2 - py35: 1.9.3 - py36: 1.12.1 - py37: 1.13.1 We have always aimed to support at least 4 numpy versions (i.e. 2 year old versions). The differences per Python version in minimum numpy version are annoying (we don't consistently check that in our main __init__.py or in setup.py even), so I propose that for SciPy 1.3.0 we raise the minimum required NumPy version to 1.13.3. That'll still be 4 supported releases, 1.13.3-1.16.x.
That's probably fine, 1.13.3 is from 2017. Situations where you are able to upgrade Scipy but not Numpy are also somewhat rare, so this seems a low-risk decision. Pauli
participants (6)
-
Evgeni Burovski -
Mark Alexander Mikofski -
Paul van Mulbregt -
Pauli Virtanen -
Ralf Gommers -
Stefan van der Walt