[Numpy-discussion] On making Numpy 1.7 a long term support release.

[Ralf Gommers]

On Sat, Feb 11, 2012 at 12:05 PM, David Cournapeau <cournape at gmail.com>wrote:

> On Sat, Feb 11, 2012 at 9:08 AM, Ralf Gommers
> <ralf.gommers at googlemail.com> wrote:
> >
> >
> > On Fri, Feb 10, 2012 at 8:51 PM, Ralf Gommers <
> ralf.gommers at googlemail.com>
> > wrote:
> >>
> >>
> >>
> >> On Fri, Feb 10, 2012 at 10:25 AM, David Cournapeau <cournape at gmail.com>
> >> wrote:
> >>>
> >>> On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers
> >>> <ralf.gommers at googlemail.com> wrote:
> >>> >
> >>> >
> >>> > On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant <travis at continuum.io
> >
> >>> > wrote:
> >>> >>
> >>> >> I think supporting Python 2.5 and above is completely fine.  I'd
> even
> >>> >> be
> >>> >> in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for
> >>> >> NumPy
> >>> >> 2.8
> >>> >>
> >>> > +1 for dropping Python 2.5 support also for an LTS release. That will
> >>> > make
> >>> > it a lot easier to use str.format() and the with statement (plus many
> >>> > other
> >>> > things) going forward, without having to think about if your changes
> >>> > can be
> >>> > backported to that LTS release.
> >>>
> >>> At the risk of sounding like a broken record, I would really like to
> >>> stay to 2.4, especially for a long term release :) This is still the
> >>> basis used by a lots of long-term python products. If we can support
> >>> 2.4 for a LTS, I would then be much more comfortable to allow bumping
> >>> to 2.5 for 1.8.
> >>
> >>
> >> At the very least someone should step up to do the testing or maintain a
> >> buildbot for Python 2.4 then. Also for scipy, assuming that scipy keeps
> >> supporting the same Python versions as numpy.
> >>
> > Here's a list of Python requirements for other important scientific
> python
> > projects:
> > - ipython: >= 2.6
> > - matplotlib: v1.1 supports 2.4-2.7, v1.2 will support >= 2.6
> > - scikit-learn: >= 2.6
> > - scikit-image: >= 2.5
> > - scikits.statsmodels: >= 2.5 (next release probably >= 2.6)
> >
> > That there are still some projects/products out there that still use
> Python
> > 2.4 (some examples of such products would be nice by the way) is not
> enough
> > of a reason by itself to continue to support it in new releases. There
> has
> > to be a good reason for those products to require the very latest numpy,
> > even though they are fine with a very old Python and older versions of
> > almost any other Python package.
>
> I don't think that last argument is relevant for a LTS.


I think it's a relevant argument right now, irrespective of whether or not
1.7 will be an LTS.


> Numpy is used in environments where you cannot easily control what's
> installed. RHEL
> still uses python 2.4 and will be supported until 2014 in the
> production phase.
>

As Bruce said, 29 Feb 2012 and not 2014:
https://access.redhat.com/support/policy/updates/errata/

Ralf

As for projects still using python 2.4, using the most downloaded
> packages from this list
> http://taichino.appspot.com/pypi_ranking/modules?page=1, most of them
> supported python 2.4 or below. lxml, zc.buildout, setuptools, pip,
> virtualenv and sqlalchemy do. Numpy itself is also used outside the
> strict scientific realm, which is why I am a bit warry about just
> comparing with other scientific python packages.
>
> Now, if everybody else is against it, I don't want to be a pain about
> it either :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120211/8cfa91f3/attachment.html>