On Thu, 13 Dec 2012 17:35:01 +0100, Travis Oliphant
wrote:
> The NumPy home page can still be edited in this repository:
> g...@github.com:numpy/numpy.org.git. Pull requests are always welcome
> --- especially pull requests that improve the look and feel of the
> web-page.
Hi,
let me
Hi all,
I have a question for the list sparked by this discussion of a bug in
NumPy 1.6.2 and 1.7:
http://mail.scipy.org/pipermail/numpy-discussion/2012-December/064682.html
and this open issue in h5py:
https://code.google.com/p/h5py/issues/detail?id=217
In h5py we need to represent variable l
+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
pro
2012/12/13 Chris Barker - NOAA Federal
> On Thu, Dec 13, 2012 at 3:01 PM, Bradley M. Froehle
> wrote:
> > Yes, but the point was that since you can live with an older version on
> > Python you can probably live with an older version of NumPy.
>
> exactly -- also:
>
> How likely are you to nee th
On Thu, Dec 13, 2012 at 7:16 PM, Charles R Harris
wrote:
>
>
> On Thu, Dec 13, 2012 at 8:04 PM, Charles R Harris
> wrote:
>>
>>
>>
>> On Thu, Dec 13, 2012 at 7:23 PM, Ondřej Čertík
>> wrote:
>>>
>>> Hi,
>>>
>>> Another weird bug sometimes happen in
>>> numpy/core/tests/test_iterator.py, it looks
On Thu, Dec 13, 2012 at 8:04 PM, Charles R Harris wrote:
>
>
> On Thu, Dec 13, 2012 at 7:23 PM, Ondřej Čertík wrote:
>
>> Hi,
>>
>> Another weird bug sometimes happen in
>> numpy/core/tests/test_iterator.py, it looks like this:
>>
>> ===
On Thu, Dec 13, 2012 at 7:23 PM, Ondřej Čertík wrote:
> Hi,
>
> Another weird bug sometimes happen in
> numpy/core/tests/test_iterator.py, it looks like this:
>
> ==
> FAIL: test_iterator.test_iter_array_cast
> ---
Hi,
Another weird bug sometimes happen in
numpy/core/tests/test_iterator.py, it looks like this:
==
FAIL: test_iterator.test_iter_array_cast
--
Traceback (most r
On Thu, Dec 13, 2012 at 3:01 PM, Bradley M. Froehle
wrote:
> Yes, but the point was that since you can live with an older version on
> Python you can probably live with an older version of NumPy.
exactly -- also:
How likely are you to nee the latest and greatest numpy but not a new
PyGTK, or a n
Hi,
I found these recent weird "failures" in Travis, but I can't find any
problem with the log and all tests pass. Any ideas what is going on?
https://travis-ci.org/numpy/numpy/jobs/3570123
https://travis-ci.org/numpy/numpy/jobs/3539549
https://travis-ci.org/numpy/numpy/jobs/3369629
Ondrej
_
Yes, but the point was that since you can live with an older version on
Python you can probably live with an older version of NumPy.
On Thursday, December 13, 2012, David Cournapeau wrote:
>
> > I"m still dumfounded that people are working on projects where they
> > are free to use the latest an g
On 12/13/2012 1:57 PM, Andrew Collette wrote:
> Hi,
>
>> the following code using np.object_ data types works with numpy 1.5.1
>> but fails with 1.6.2. Is this intended or a regression? Other data
>> types, np.float64 for example, seem to work.
>
> I am also seeing this problem; there was a change
On Thu, Dec 13, 2012 at 10:07 PM, Chris Barker - NOAA Federal
wrote:
How about dropping support for python 2.5 also?
>
> I"m still dumfounded that people are working on projects where they
> are free to use the latest an greatest numpy, but *have* to use a
> more-than-four-year-old-python:
I
Hi,
> the following code using np.object_ data types works with numpy 1.5.1
> but fails with 1.6.2. Is this intended or a regression? Other data
> types, np.float64 for example, seem to work.
I am also seeing this problem; there was a change to how string types
are handled in h5py 2.1.0 which tri
>>> How about dropping support for python 2.5 also?
I"m still dumfounded that people are working on projects where they
are free to use the latest an greatest numpy, but *have* to use a
more-than-four-year-old-python:
"""
Python 2.6 (final) was released on October 1st, 2008.
"""
so +1 on moving
On Dec 13, 2012, at 2:47 PM, Charles R Harris wrote:
> On Thu, Dec 13, 2012 at 12:26 PM, Philip Semanchuk
> wrote:
>
>> Hi all,
>> I'm porting some Fortran code that makes use of a number of BLAS and
>> LAPACK functions, including dbdsqr(). I've found all of the functions I
>> need via scipy.li
On Dec 13, 2012, at 3:03 PM, Pauli Virtanen wrote:
> 13.12.2012 21:26, Philip Semanchuk kirjoitti:
>> I'm porting some Fortran code that makes use of a number of BLAS and
>> LAPACK functions, including dbdsqr(). I've found all of the functions
>> I need via scipy.linalg.lapack.get_lapack_funcs/ge
On Thu, Dec 13, 2012 at 6:36 PM, Charles R Harris wrote:
>
>
> On Thu, Dec 13, 2012 at 10:12 AM, Bradley M. Froehle <
> brad.froe...@gmail.com> wrote:
>
>> Targeting >= 2.6 would be preferable to me. Several other packages
>> including IPython, support only Python >= 2.6, >= 3.2.
>>
>> This chan
13.12.2012 21:26, Philip Semanchuk kirjoitti:
> I'm porting some Fortran code that makes use of a number of BLAS and
> LAPACK functions, including dbdsqr(). I've found all of the functions
> I need via scipy.linalg.lapack.get_lapack_funcs/get_blas_funcs() except
> for dbdsqr().
[clip]
If you toler
On Thu, Dec 13, 2012 at 12:26 PM, Philip Semanchuk wrote:
> Hi all,
> I'm porting some Fortran code that makes use of a number of BLAS and
> LAPACK functions, including dbdsqr(). I've found all of the functions I
> need via scipy.linalg.lapack.get_lapack_funcs/get_blas_funcs() except for
> dbdsqr(
Hi all,
I'm porting some Fortran code that makes use of a number of BLAS and LAPACK
functions, including dbdsqr(). I've found all of the functions I need via
scipy.linalg.lapack.get_lapack_funcs/get_blas_funcs() except for dbdsqr().
I see that the numpy source code (I looked at numpy-1.6.0b2) c
On 12/13/2012 07:59 PM, David Cournapeau wrote:
> On Fri, Dec 7, 2012 at 7:58 PM, Dag Sverre Seljebotn
> wrote:
>> One way of fixing this I'm sort of itching to do is to create a
>> "pylapack" project which can iterate quickly on these build issues,
>> run-time selection of LAPACK backend and so o
On Fri, Dec 7, 2012 at 7:58 PM, Dag Sverre Seljebotn
wrote:
> One way of fixing this I'm sort of itching to do is to create a
> "pylapack" project which can iterate quickly on these build issues,
> run-time selection of LAPACK backend and so on. (With some templates
> generating some Cython code i
On Thu, Dec 13, 2012 at 7:12 PM, Benjamin Root wrote:
> On Thu, Dec 13, 2012 at 12:38 PM, Charles R Harris
> wrote:
>>
>> The previous proposal to drop python 2.4 support garnered no opposition.
>> How about dropping support for python 2.5 also?
>>
>> Chuck
>>
>
> matplotlib 1.2 supports py2.5.
My apologies... we support 2.6 and above. +1 on dropping 2.5 support.
Ben
On Thu, Dec 13, 2012 at 1:12 PM, Benjamin Root wrote:
> On Thu, Dec 13, 2012 at 12:38 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> The previous proposal to drop python 2.4 support garnered no oppositio
On Thu, Dec 13, 2012 at 12:38 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
> The previous proposal to drop python 2.4 support garnered no opposition.
> How about dropping support for python 2.5 also?
>
> Chuck
>
>
matplotlib 1.2 supports py2.5. I haven't seen any plan to move off of t
On 12/07/2012 07:58 PM, Dag Sverre Seljebotn wrote:
> One way of fixing this I'm sort of itching to do is to create a
> "pylapack" project which can iterate quickly on these build issues,
> run-time selection of LAPACK backend and so on. (With some templates
> generating some Cython code it shouldn
I'd say it's a good idea, although I hope 1.7.x will still be maintained
for a while for those who are still stuck with Python 2.4-5 (sometimes you
don't have a choice).
-=- Olivier
2012/12/13 Charles R Harris
> The previous proposal to drop python 2.4 support garnered no opposition.
> How abou
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 d
The previous proposal to drop python 2.4 support garnered no opposition.
How about dropping support for python 2.5 also?
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 n
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 h
Yes, and ditto for SciPy.
With dropped 2.4 support we can also use the new memoryview syntax instead of
ndarray syntax in Cython. That is more important for SciPy, but it has some
relevance for NumPy too.
Sturla
Sendt fra min iPad
Den 13. des. 2012 kl. 17:34 skrev Charles R Harris :
> Time t
On Thu, Dec 13, 2012 at 12:00 PM, David Cournapeau wrote:
> I would even go as far as dropping 2.5 as well then (RHEL 6
> uses python 2.6).
+1
Skipper
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/
On Thu, Dec 13, 2012 at 5:34 PM, Charles R Harris
wrote:
> Time to raise this topic again. Opinions welcome.
I am ok if 1.7 is the LTS. I would even go as far as dropping 2.5 as
well then (RHEL 6 uses python 2.6).
cheers,
David
___
NumPy-Discussion mai
+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 nump
+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 wrot
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...
Ben Root
_
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-Discus
For people interested in the www.numpy.org home page:
Jon Turner has officially transferred the www.numpy.org domain to NumFOCUS.
Thank you, Jon for this donation and for being a care-taker of the
domain-name. We have setup the domain registration to point to
numpy.github.com and I've ch
I'd be happy with disallowing floating point index at all. I would think it
was
almost always a mistake.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
41 matches
Mail list logo
