On 12/13/2012 09:39 AM, Benjamin Root wrote:

As a point of reference, python 2.4 is on RH5/CentOS5. While RH6 is the current version, there are still enterprises that are using version 5. Of course, at this point, one really should be working on a migration plan and shouldn't be doing new development on those machines...

FWIW this RHEL5* shop uses a local install of 2.6 rather than dealing with 2.4. Happy with dropping 2.4 support. Bonus from dropping 2.5: it's pretty easy to support a 2.6/3.x combined codebase without relying on 2to3. (*Not the same as RH5, from days of yore...) -- Jonathan Niehof ISR-3 Space Data Systems Los Alamos National Laboratory MS-D466 Los Alamos, NM 87545 Phone: 505-667-9595 email: jniehof@lanl.gov Correspondence / Technical data or Software Publicly Available

+1, especially if this is for 1.8. What is the plan for when it will be released? It is 1.7 that will be the long term supported version? Fred On Thu, Dec 13, 2012 at 11:46 AM, Anthony Scopatz wrote:

+1, if someone wants to use an older version of Python they can use an older version of numpy.

On Thu, Dec 13, 2012 at 10:36 AM, Travis Oliphant wrote:

...

A big +1 from me --- but I don't have anyone I know using 2.4 anymore....

-Travis

On Dec 13, 2012, at 10:34 AM, Charles R Harris wrote:

...

Time to raise this topic again. Opinions welcome.

Chuck _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

On Thu, Dec 13, 2012 at 12:00 PM, David Cournapeau wrote: <snip>

I would even go as far as dropping 2.5 as well then (RHEL 6 uses python 2.6).

+1 Skipper

On Thu, Dec 13, 2012 at 10:12 AM, Bradley M. Froehle

wrote:

Targeting >= 2.6 would be preferable to me. Several other packages including IPython, support only Python >= 2.6, >= 3.2.

This change would help me from accidentally writing Python syntax which is allowable in 2.6 & 2.7 (but not in 2.4 or 2.5).

Compiling a newer Python interpreter isn't very hard… probably about as difficult as installing NumPy.

-Brad

On Thursday, December 13, 2012 at 9:03 AM, Skipper Seabold wrote:

...

On Thu, Dec 13, 2012 at 12:00 PM, David Cournapeau wrote: <snip>

...

I would even go as far as dropping 2.5 as well then (RHEL 6 uses python 2.6).

+1

OK. Dropping support for python 2.4 looks like the majority opinion. I'll put up another post for 2.5. Do we need to coordinate with scipy? Chuck

So when upgrading everything you prefer to keep the bugs in 2.6 that were squashed in 2.7? Who has taught IT managers that older and more buggy versions of software are more "professional" and better for corporate environments? Sturla Den 14. des. 2012 kl. 05:14 skrev Raul Cota :

+1 from me

For what is worth, we are just moving forward from Python 2.2 / Numeric and are going to 2.6 and it has been rather painful because of the several little details of extensions and other subtleties. I believe we will settle there for a while. For companies like ours, it is a big problem to upgrade versions. There is always this or that hiccup that "works great" in a version but not so much in another and we also have all sorts of extensions.

Raul

On 13/12/2012 9:34 AM, Charles R Harris wrote:

...

Time to raise this topic again. Opinions welcome.

Chuck

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

On 14 Dec 2012 04:14, "Raul Cota" wrote:

+1 from me

For what is worth, we are just moving forward from Python 2.2 / Numeric and are going to 2.6 and it has been rather painful because of the several little details of extensions and other subtleties. I believe we will settle there for a while. For companies like ours, it is a big problem to upgrade versions. There is always this or that hiccup that "works great" in a version but not so much in another and we also have all sorts of extensions.

Unfortunately (and I know this is a tradeoff), one consequence of this strategy is that you give up the chance to influence numpy development and avoid those hiccups in the first place. We try to catch things, but there's a *lot* more we can do if a bug gets noticed before it makes it into a final release, or multiple final releases... (This is why 1.7 has been dragging on - people testing the RCs found a number of places that it broke there code, so we're fixing numpy instead of them having to fix their code.) -n