[SciPy-Dev] dropping python 2.7 and numpy <1.13.3

Mon Nov 12 23:00:17 EST 2018

> 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 at 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-proposal.rst
> 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 at gmail.com> wrote:
>
>
>
> On Sun, Nov 11, 2018 at 10:28 AM Paul van Mulbregt <
> p.vanmulbregt at 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-.2B-_compiler_to_use_with_a_specific_Python_version_.3F
>>
>> -Paul
>>
>>
>> On Nov 11, 2018, at 5:07 AM, Evgeni Burovski <evgeny.burovskiy at 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 at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>

-- 
Mark Mikofski, PhD (2005)
*Fiat Lux*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20181112/d809bd30/attachment-0001.html>