Re: [Numpy-discussion] draft release guide
A Wednesday 24 March 2010 01:49:50 Ralf Gommers escrigué: On Wed, Mar 24, 2010 at 1:40 AM, Christopher Barker chris.bar...@noaa.govwrote: Ralf Gommers wrote: At http://github.com/rgommers/NumPy-release-guide you can find a summary of how to set up your system to build numpy binaries on OS X. I still have to add info on scipy (that's turning out to be fairly painful) but for numpy it is pretty complete. Any feedback is appreciated! We really don't want to supply binaries for python 2.5 anymore? (maybe this will get me to finally switch! That's fast, I was hoping to get away with that one! I discussed a bit with David, and he suggested to not make 2.5 binaries for scipy 0.7.2 and then see if there was still any demand. It's a lot of work with perhaps not so much return. Of course a maintenance release of scipy with no new features may be a different story from a new release of numpy/scipy. So by no means is this decided or even publicly discussed. I do want to point out that we have not provided 2.4 binaries for a while without much demand. So now the question: who still wants and uses 2.5 binaries? I do. I think at least 2 binary versions is a recommendable practice for allowing people to change versions more comfortably. Also, I have read the draft and I cannot see references to 64-bit binary packages. With the advent of Windows 7 and Mac OSX Snow Leopard, 64-bit are way more spread than before, so they would be a great thing to deliver, IMO. Thanks, -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] draft release guide
On Wed, Mar 24, 2010 at 5:50 PM, Francesc Alted fal...@pytables.org wrote: A Wednesday 24 March 2010 01:49:50 Ralf Gommers escrigué: On Wed, Mar 24, 2010 at 1:40 AM, Christopher Barker chris.bar...@noaa.govwrote: Ralf Gommers wrote: At http://github.com/rgommers/NumPy-release-guide you can find a summary of how to set up your system to build numpy binaries on OS X. I still have to add info on scipy (that's turning out to be fairly painful) but for numpy it is pretty complete. Any feedback is appreciated! We really don't want to supply binaries for python 2.5 anymore? (maybe this will get me to finally switch! That's fast, I was hoping to get away with that one! I discussed a bit with David, and he suggested to not make 2.5 binaries for scipy 0.7.2 and then see if there was still any demand. It's a lot of work with perhaps not so much return. Of course a maintenance release of scipy with no new features may be a different story from a new release of numpy/scipy. So by no means is this decided or even publicly discussed. I do want to point out that we have not provided 2.4 binaries for a while without much demand. So now the question: who still wants and uses 2.5 binaries? I do. I think at least 2 binary versions is a recommendable practice for allowing people to change versions more comfortably. Okay thanks, that's two people already so I'll try. Also, I have read the draft and I cannot see references to 64-bit binary packages. With the advent of Windows 7 and Mac OSX Snow Leopard, 64-bit are way more spread than before, so they would be a great thing to deliver, IMO. The reason is that for OS X the binaries from python.org are 32-bit only so far. Apple Python is 64-bit, but seems to have its own issues (way behind with bug fix releases, maybe there's more). David told me to always only target the python.org version, which makes sense to me. For Windows 7, I agree it's worth looking into 64-bits binaries, but can't tell you right now how easy that would be. Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] draft release guide
On Wed, Mar 24, 2010 at 6:50 PM, Francesc Alted fal...@pytables.org wrote: Also, I have read the draft and I cannot see references to 64-bit binary packages. With the advent of Windows 7 and Mac OSX Snow Leopard, 64-bit are way more spread than before, so they would be a great thing to deliver, IMO. For Mac OS X, we should wait for official 64 bits binaries from python.org - EPD offers 64 bits binaries if necessary. On windows, the situation is more complicated, because there is no way to build numpy and scipy correctly with free compilers. For various reasons, I think we should avoid distributing binaries based on non-free compilers (not available to everyone, problem of compatibility and redistribution of non-free code, especially for fortran) - and for people who don't mind/care, there are unofficial win64 binaries out there (we may put a link somewhere). Unfortunately, I don't think I will have much time to spend on making scipy and gfortran work together on win64 in the near future, cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] StringIO test failure with Python3.1.2
Hi, Wow, this is really impressive! I installed the svn numpy version '2.0.0.dev8300' with the latest Python 3.1.2 and it works! All the tests pass except: test_utils.test_lookfor I am guessing that it is this line as the other io imports do not have the period. from .io import StringIO == ERROR: test_utils.test_lookfor -- Traceback (most recent call last): File /usr/local/lib/python3.1/site-packages/nose/case.py, line 177, in runTest self.test(*self.arg) File /usr/local/lib/python3.1/site-packages/numpy/lib/tests/test_utils.py, line 10, in test_lookfor import_modules=False) File /usr/local/lib/python3.1/site-packages/numpy/lib/utils.py, line 751, in lookfor cache = _lookfor_generate_cache(module, import_modules, regenerate) File /usr/local/lib/python3.1/site-packages/numpy/lib/utils.py, line 852, in _lookfor_generate_cache from .io import StringIO ImportError: cannot import name StringIO -- Ran 2898 tests in 24.646s FAILED (KNOWNFAIL=5, errors=1) nose.result.TextTestResult run=2898 errors=1 failures=0 Bruce ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] draft release guide
A Wednesday 24 March 2010 12:00:36 David Cournapeau escrigué: On Wed, Mar 24, 2010 at 6:50 PM, Francesc Alted fal...@pytables.org wrote: Also, I have read the draft and I cannot see references to 64-bit binary packages. With the advent of Windows 7 and Mac OSX Snow Leopard, 64-bit are way more spread than before, so they would be a great thing to deliver, IMO. For Mac OS X, we should wait for official 64 bits binaries from python.org - EPD offers 64 bits binaries if necessary. On windows, the situation is more complicated, because there is no way to build numpy and scipy correctly with free compilers. For various reasons, I think we should avoid distributing binaries based on non-free compilers (not available to everyone, problem of compatibility and redistribution of non-free code, especially for fortran) - and for people who don't mind/care, there are unofficial win64 binaries out there (we may put a link somewhere). Unfortunately, I don't think I will have much time to spend on making scipy and gfortran work together on win64 in the near future, Ok. I've been having a try at mingw-w64 project: http://mingw-w64.sourceforge.net/ with no success so far with build numpy: $ python setup.py build --compiler=mingw32 [...] Found executable C:\mingw-w64_x86_64-mingw\mingw64\bin\gcc.exe g++ -mno-cygwin _configtest.o -lmsvcr90 -o _configtest.exe Found executable C:\mingw-w64_x86_64-mingw\mingw64\bin\g++.exe c:/mingw-w64_x86_64-mingw/mingw64/bin/../lib/gcc/x86_64-w64- mingw32/4.4.4/../../ ../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lmsvcr90 collect2: ld returned 1 exit status failure. [...] However, I can compile it with plain mingw tool chain (obviously, only can get w32 binaries). Any hint on how to proceed with mingw-w64? Thanks, -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] draft release guide
On Wed, Mar 24, 2010 at 11:25 PM, Francesc Alted fal...@pytables.org wrote: Ok. I've been having a try at mingw-w64 project: http://mingw-w64.sourceforge.net/ with no success so far with build numpy: $ python setup.py build --compiler=mingw32 Oh, it is not that easy :) First, for some reason, the mingw-w64 project does not provide 64 hosted compilers, and since pushing for mingw cross compilation support in distutils would redefine the meaning of insanity, I build my gcc. Since building gcc on windows is not a fun ride either, you have to build it on unix (I have the scripts on my github account: github.com/cournape/). Then, you can hope to build numpy with mingw 64 on windows 64. But then, it randomly crashes, and last time I looked at it (~ 8 months ago), there was no gdb support and the mingw debug symbols cannot be understood by MS tools, so I was stuck at trying to understand what went wrong without a meaningful backtrace. I also looked into making gfortran works with MS compiler, but this means porting libgfortran to something MS compilers can understand. This is not as crazy as it sounds, because we don't use many fortran runtime functions in scipy. Of course, atlas on windows 64 is nowhere near buildable. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
Any idea why from .io import StringIO and not from io import StringIO ??? (Why is the extra . before io) Nadav -Original Message- From: numpy-discussion-boun...@scipy.org on behalf of Bruce Southey Sent: Wed 24-Mar-10 16:17 To: Discussion of Numerical Python Subject: [Numpy-discussion] StringIO test failure with Python3.1.2 Hi, Wow, this is really impressive! I installed the svn numpy version '2.0.0.dev8300' with the latest Python 3.1.2 and it works! All the tests pass except: test_utils.test_lookfor I am guessing that it is this line as the other io imports do not have the period. from .io import StringIO == ERROR: test_utils.test_lookfor -- Traceback (most recent call last): File /usr/local/lib/python3.1/site-packages/nose/case.py, line 177, in runTest self.test(*self.arg) File /usr/local/lib/python3.1/site-packages/numpy/lib/tests/test_utils.py, line 10, in test_lookfor import_modules=False) File /usr/local/lib/python3.1/site-packages/numpy/lib/utils.py, line 751, in lookfor cache = _lookfor_generate_cache(module, import_modules, regenerate) File /usr/local/lib/python3.1/site-packages/numpy/lib/utils.py, line 852, in _lookfor_generate_cache from .io import StringIO ImportError: cannot import name StringIO -- Ran 2898 tests in 24.646s FAILED (KNOWNFAIL=5, errors=1) nose.result.TextTestResult run=2898 errors=1 failures=0 Bruce ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion winmail.dat___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
On Wed, Mar 24, 2010 at 11:35 PM, Nadav Horesh nad...@visionsense.com wrote: Any idea why from .io import StringIO and not from io import StringIO ??? (Why is the extra . before io) Maybe a bug in py2to3, because StringIO is in io in python 3, and we have a io module in numpy (.io is the new syntax for relative import). David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
On Wed, Mar 24, 2010 at 09:43, David Cournapeau courn...@gmail.com wrote: On Wed, Mar 24, 2010 at 11:35 PM, Nadav Horesh nad...@visionsense.com wrote: Any idea why from .io import StringIO and not from io import StringIO ??? (Why is the extra . before io) Maybe a bug in py2to3, because StringIO is in io in python 3, and we have a io module in numpy (.io is the new syntax for relative import). Ignore my previous email. This is the correct answer. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
On Wed, Mar 24, 2010 at 09:35, Nadav Horesh nad...@visionsense.com wrote: Any idea why from .io import StringIO and not from io import StringIO ??? (Why is the extra . before io) It is a relative import, i.e. numpy.lib.io . -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
On Wed, Mar 24, 2010 at 09:43, David Cournapeau courn...@gmail.com wrote: On Wed, Mar 24, 2010 at 11:35 PM, Nadav Horesh nad...@visionsense.com wrote: Any idea why from .io import StringIO and not from io import StringIO ??? (Why is the extra . before io) Maybe a bug in py2to3, because StringIO is in io in python 3, and we have a io module in numpy (.io is the new syntax for relative import). Bug reported: http://bugs.python.org/issue8221 -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
On Wed, Mar 24, 2010 at 9:07 AM, Robert Kern robert.k...@gmail.com wrote: On Wed, Mar 24, 2010 at 09:43, David Cournapeau courn...@gmail.com wrote: On Wed, Mar 24, 2010 at 11:35 PM, Nadav Horesh nad...@visionsense.com wrote: Any idea why from .io import StringIO and not from io import StringIO ??? (Why is the extra . before io) Maybe a bug in py2to3, because StringIO is in io in python 3, and we have a io module in numpy (.io is the new syntax for relative import). Bug reported: http://bugs.python.org/issue8221 What would be the best fix? Should we rename io to something like npyio? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
On Wed, Mar 24, 2010 at 10:20, Charles R Harris charlesr.har...@gmail.com wrote: On Wed, Mar 24, 2010 at 9:07 AM, Robert Kern robert.k...@gmail.com wrote: On Wed, Mar 24, 2010 at 09:43, David Cournapeau courn...@gmail.com wrote: On Wed, Mar 24, 2010 at 11:35 PM, Nadav Horesh nad...@visionsense.com wrote: Any idea why from .io import StringIO and not from io import StringIO ??? (Why is the extra . before io) Maybe a bug in py2to3, because StringIO is in io in python 3, and we have a io module in numpy (.io is the new syntax for relative import). Bug reported: http://bugs.python.org/issue8221 What would be the best fix? Should we rename io to something like npyio? utils.py is the only file in there that imports StringIO. It should probably do a local import from io import BytesIO because io.py already contains some Python3-awareness: if sys.version_info[0] = 3: import io BytesIO = io.BytesIO else: from cStringIO import StringIO as BytesIO -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
ke, 2010-03-24 kello 09:20 -0600, Charles R Harris kirjoitti: What would be the best fix? Should we rename io to something like npyio? That, or: Disable import conversions in tools/py3tool.py for that particular file, and fix any import errors manually so that the same code works both for Python 2 and Python 3. Actually, I suspect there are no import errors, since the top-level imports in that file are already absolute. Anyway, it's a bug in 2to3. I suppose it first converts from StringIO import StringIO to from io import StringIO and then runs the import fixer, which does from .io import StringIO and that's a bug. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
ke, 2010-03-24 kello 10:28 -0500, Robert Kern kirjoitti: utils.py is the only file in there that imports StringIO. It should probably do a local import from io import BytesIO because io.py already contains some Python3-awareness: if sys.version_info[0] = 3: import io BytesIO = io.BytesIO else: from cStringIO import StringIO as BytesIO The lookfor stuff in utils.py deals with docstrings, so it probably has to use StringIO instead of BytesIO for unicode-cleanliness. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
On Wed, Mar 24, 2010 at 9:29 AM, Pauli Virtanen p...@iki.fi wrote: ke, 2010-03-24 kello 09:20 -0600, Charles R Harris kirjoitti: What would be the best fix? Should we rename io to something like npyio? That, or: Disable import conversions in tools/py3tool.py for that particular file, and fix any import errors manually so that the same code works both for Python 2 and Python 3. Actually, I suspect there are no import errors, since the top-level imports in that file are already absolute. I have some preference for the name change just to avoid shadowing a standard module, it makes numpy just a bit safer. Anyway, it's a bug in 2to3. I suppose it first converts from StringIO import StringIO to from io import StringIO and then runs the import fixer, which does from .io import StringIO and that's a bug. Sounds right. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
On 03/24/2010 10:30 AM, Pauli Virtanen wrote: ke, 2010-03-24 kello 10:28 -0500, Robert Kern kirjoitti: utils.py is the only file in there that imports StringIO. It should probably do a local import from io import BytesIO because io.py already contains some Python3-awareness: if sys.version_info[0]= 3: import io BytesIO = io.BytesIO else: from cStringIO import StringIO as BytesIO The lookfor stuff in utils.py deals with docstrings, so it probably has to use StringIO instead of BytesIO for unicode-cleanliness. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion This appears to be a regression because I do not get the error with Python 3.1.1. I rebuilt Python3.1.1 and Python3.1.2 to compare the builds (I don't know how to keep the two Python 3.1 minor releases separate). From the diff it is clear that Python3.1.2 (build directory) is adding the .io but the Python3.1.1 (build311 directory). $ diff build/py3k/numpy/lib/utils.py build311/py3k/numpy/lib/utils.py 8d7 import collections 852c851 from .io import StringIO --- from io import StringIO 945c944 elif isinstance(item, collections.Callable): --- elif hasattr(item, '__call__'): Bruce ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
On Wed, Mar 24, 2010 at 9:59 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Wed, Mar 24, 2010 at 9:29 AM, Pauli Virtanen p...@iki.fi wrote: ke, 2010-03-24 kello 09:20 -0600, Charles R Harris kirjoitti: What would be the best fix? Should we rename io to something like npyio? That, or: Disable import conversions in tools/py3tool.py for that particular file, and fix any import errors manually so that the same code works both for Python 2 and Python 3. Actually, I suspect there are no import errors, since the top-level imports in that file are already absolute. I have some preference for the name change just to avoid shadowing a standard module, it makes numpy just a bit safer. In particular, here are the current occurences of io numpy/lib/__init__.py:from io import * numpy/lib/tests/test__iotools.py:from io import BytesIO numpy/lib/tests/test_format.py:... from io import BytesIO as StringIO numpy/lib/tests/test_format.py:from io import BytesIO as StringIO numpy/lib/tests/test_io.py:from io import BytesIO And it looks to me like that could easily get confusing since io is also a Python module since 2.6. snip Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] draft release guide
Francesc Alted wrote: Also, I have read the draft and I cannot see references to 64-bit binary packages. With the advent of Windows 7 and Mac OSX Snow Leopard, 64-bit are way more spread than before, so they would be a great thing to deliver, IMO. True, however the situation is a bit ugly with OS-X -- python.org does not distribute 64 bit binaries at all, and Apple's Python is a bit weird in that regard. Also some key libraries (anything build on Carbon , such as wxPython) don't work on 64 bit. That being said, a 32+64 bit build for the Apple supplied Python for OS-X 10.6 might be nice, though a bit of a niche market. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
On Wed, Mar 24, 2010 at 8:17 AM, Bruce Southey bsout...@gmail.com wrote: Hi, Wow, this is really impressive! I installed the svn numpy version '2.0.0.dev8300' with the latest Python 3.1.2 and it works! All the tests pass except: test_utils.test_lookfor I am guessing that it is this line as the other io imports do not have the period. from .io import StringIO I went ahead and renamed lib/io.py to lib/npyio.py in r8302. Can you give it a try? you might need to rm the build/py3k directory first to make it work. snip Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
On 03/24/2010 01:25 PM, Charles R Harris wrote: On Wed, Mar 24, 2010 at 8:17 AM, Bruce Southey bsout...@gmail.com mailto:bsout...@gmail.com wrote: Hi, Wow, this is really impressive! I installed the svn numpy version '2.0.0.dev8300' with the latest Python 3.1.2 and it works! All the tests pass except: test_utils.test_lookfor I am guessing that it is this line as the other io imports do not have the period. from .io import StringIO I went ahead and renamed lib/io.py to lib/npyio.py in r8302. Can you give it a try? you might need to rm the build/py3k directory first to make it work. snip Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion I get a different error because it also has 'import collections'. $ python3.1 Python 3.1.2 (r312:79147, Mar 24 2010, 10:44:23) [GCC 4.4.3 20100127 (Red Hat 4.4.3-4)] on linux2 Type help, copyright, credits or license for more information. import numpy numpy.__version__ '2.0.0.dev8302' numpy.test() Running unit tests for numpy NumPy version 2.0.0.dev8302 NumPy is installed in /usr/local/lib/python3.1/site-packages/numpy Python version 3.1.2 (r312:79147, Mar 24 2010, 10:44:23) [GCC 4.4.3 20100127 (Red Hat 4.4.3-4)] nose version 0.11.0 . == ERROR: test_utils.test_lookfor -- Traceback (most recent call last): File /usr/local/lib/python3.1/site-packages/nose/case.py, line 177, in runTest self.test(*self.arg) File /usr/local/lib/python3.1/site-packages/numpy/lib/tests/test_utils.py, line 10, in test_lookfor import_modules=False) File /usr/local/lib/python3.1/site-packages/numpy/lib/utils.py, line 751, in lookfor cache = _lookfor_generate_cache(module, import_modules, regenerate) File /usr/local/lib/python3.1/site-packages/numpy/lib/utils.py, line 945, in _lookfor_generate_cache elif isinstance(item, collections.Callable): File /usr/local/lib/python3.1/abc.py, line 121, in __instancecheck__ subclass = instance.__class__ AttributeError: 'PyCapsule' object has no attribute '__class__' -- Ran 2898 tests in 21.738s FAILED (KNOWNFAIL=5, errors=1) nose.result.TextTestResult run=2898 errors=1 failures=0 $ diff build/py3k/build/lib.linux-x86_64-3.1/numpy/lib/utils.py build311/py3k/build/lib.linux-x86_64-3.1/numpy/lib/utils.py 8d7 import collections 945c944 elif isinstance(item, collections.Callable): --- elif hasattr(item, '__call__'): ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] StringIO test failure with Python3.1.2
Wed, 24 Mar 2010 13:35:51 -0500, Bruce Southey wrote: [clip] elif isinstance(item, collections.Callable): File /usr/local/lib/python3.1/abc.py, line 121, in __instancecheck__ subclass = instance.__class__ AttributeError: 'PyCapsule' object has no attribute '__class__' Seems like another Python bug. All objects probably should have the __class__ attribute... -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy.array(arr.flat) mutates arr if arr.flags.fortran: bug?
Hello,
I assume it is a bug that calling numpy.array() on a flatiter of a
fortran-strided array that owns its own data causes that array to be
rearranged somehow?
Not sure what happens with a fancier-strided array that also owns its
own data (because I'm not sure how to create one of those in python).
This is from the latest svn version (2.0.0.dev8302) but was also
present in a previous version too.
Zach
In [9]: a = numpy.array([[1,2],[3,4]]).copy('F')
In [10]: a
Out[10]:
array([[1, 2],
[3, 4]])
In [11]: list(a.flat)
Out[11]: [1, 2, 3, 4]
In [12]: a # no problem
Out[12]:
array([[1, 2],
[3, 4]])
In [13]: numpy.array(a.flat)
Out[13]: array([1, 2, 3, 4])
In [14]: a # this ain't right!
Out[14]:
array([[1, 3],
[2, 4]])
In [15]: a = numpy.array([[1,2],[3,4]]).copy('C')
In [16]: numpy.array(a.flat)
Out[16]: array([1, 2, 3, 4])
In [17]: a
Out[17]:
array([[1, 2],
[3, 4]])
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] draft release guide
A Wednesday 24 March 2010 15:38:58 David Cournapeau escrigué: Oh, it is not that easy :) First, for some reason, the mingw-w64 project does not provide 64 hosted compilers, and since pushing for mingw cross compilation support in distutils would redefine the meaning of insanity, I build my gcc. Since building gcc on windows is not a fun ride either, you have to build it on unix (I have the scripts on my github account: github.com/cournape/). Mmh, not sure about what you mean by hosted compiler, but there is certainly a native compiler package for Win64: mingw-w64-bin_x86_64-mingw_20100322_sezero.zip It comes with gcc, g++ and gfortran 4.4.4. gdb support is also there. So it seems like a pretty complete toolset for windows amd64. With it, and with some fixes in numpy sources (very few), I achieved to pass the build phase. I can provide the patch in case someone is interested. The generated extensions are: 24/03/2010 19:34 1.492.313 multiarray.pyd 24/03/2010 19:34 124.866 multiarray_tests.pyd 24/03/2010 19:34 453.377 scalarmath.pyd 24/03/2010 19:34 1.079.827 umath.pyd 24/03/2010 19:34 121.651 umath_tests.pyd 24/03/2010 19:34 304.014 _sort.pyd which looks good to my eyes. Now, when I try to generate the installable package I'm in trouble again: $ python setup.py bdist [...] File C: \Users\francesc\Desktop\NumPy\1.4.x\numpy\distutils\command\config.py , line 56, in _check_compiler self.compiler.initialize() File C:\Python26_64\lib\distutils\msvc9compiler.py, line 359, in initialize vc_env = query_vcvarsall(VERSION, plat_spec) File C:\Python26_64\lib\distutils\msvc9compiler.py, line 275, in query_vcvar sall raise ValueError(str(list(result.keys( ValueError: [u'path'] [...] So, it looks like either numpy or python cannot determine that the used compiler is mingw instead of msvc9. However, when I try to specify mingw explicitly, I get the next error: $ python setup.py bdist --compiler=mingw32 Running from numpy source directory. Forcing DISTUTILS_USE_SDK=1 usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: option --compiler not recognized Someone could tell me why distutils can be told to use mingw32 compiler for the build stage but not for bdist? What is more, why the need for a compiler for bdist if numpy is already built? I feel that I'm almost there, but some piece still resists... -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] draft release guide
On Wed, Mar 24, 2010 at 3:31 PM, Francesc Alted fal...@pytables.org wrote: A Wednesday 24 March 2010 15:38:58 David Cournapeau escrigué: Oh, it is not that easy :) First, for some reason, the mingw-w64 project does not provide 64 hosted compilers, and since pushing for mingw cross compilation support in distutils would redefine the meaning of insanity, I build my gcc. Since building gcc on windows is not a fun ride either, you have to build it on unix (I have the scripts on my github account: github.com/cournape/). Mmh, not sure about what you mean by hosted compiler, but there is certainly a native compiler package for Win64: mingw-w64-bin_x86_64-mingw_20100322_sezero.zip It comes with gcc, g++ and gfortran 4.4.4. gdb support is also there. So it seems like a pretty complete toolset for windows amd64. With it, and with some fixes in numpy sources (very few), I achieved to pass the build phase. I can provide the patch in case someone is interested. The generated extensions are: 24/03/2010 19:34 1.492.313 multiarray.pyd 24/03/2010 19:34 124.866 multiarray_tests.pyd 24/03/2010 19:34 453.377 scalarmath.pyd 24/03/2010 19:34 1.079.827 umath.pyd 24/03/2010 19:34 121.651 umath_tests.pyd 24/03/2010 19:34 304.014 _sort.pyd which looks good to my eyes. Now, when I try to generate the installable package I'm in trouble again: $ python setup.py bdist [...] File C: \Users\francesc\Desktop\NumPy\1.4.x\numpy\distutils\command\config.py , line 56, in _check_compiler self.compiler.initialize() File C:\Python26_64\lib\distutils\msvc9compiler.py, line 359, in initialize vc_env = query_vcvarsall(VERSION, plat_spec) File C:\Python26_64\lib\distutils\msvc9compiler.py, line 275, in query_vcvar sall raise ValueError(str(list(result.keys( ValueError: [u'path'] [...] So, it looks like either numpy or python cannot determine that the used compiler is mingw instead of msvc9. However, when I try to specify mingw explicitly, I get the next error: $ python setup.py bdist --compiler=mingw32 Running from numpy source directory. Forcing DISTUTILS_USE_SDK=1 usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: option --compiler not recognized For some similar problems, which I don't remember exactly, I needed to create the dist in the same command as the build, e.g. python setup.py build --compiler=mingw32 bdist I don't know if this works in your case, I have the compiler specified in distutils.cfg Josef Someone could tell me why distutils can be told to use mingw32 compiler for the build stage but not for bdist? What is more, why the need for a compiler for bdist if numpy is already built? I feel that I'm almost there, but some piece still resists... -- Francesc Alted ___ 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] What does float64 mean on a 32-bit machine?
How can I have a float64 dtype on a 32-bit machine? For example: In [90]: x = array([1/3],dtype=float32) In [91]: x Out[91]: array([ 0.3334], dtype=float32) In [92]: x = array([1/3],dtype=float64) In [93]: x Out[93]: array([ 0.]) Obviously, the float32 and float64 representations of 1/3 are different, but what is the meaning of float64 on a 32-bit machine? Shouldn't a 32-bit machine only be able represent float32? Thanks! ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] What does float64 mean on a 32-bit machine?
On Wed, Mar 24, 2010 at 17:38, reckoner recko...@gmail.com wrote: How can I have a float64 dtype on a 32-bit machine? For example: float64 is a 64-bit float on all machines. A 32-bit machine refers only to the size of its memory address space and the size of the integer type used for pointers. It has no effect on floating point types; 32- and 64-bit versions are standard on all supported platforms though the higher precisions vary significantly from machine to machine regardless of whether it is 32- or 64-bit. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] What does float64 mean on a 32-bit machine?
reckoner wrote: How can I have a float64 dtype on a 32-bit machine? For example: float64 is known as double in C, just for this reason. Modern FPUs use 64 bit (actually more bits), so you can get very good performance with float64 on 32 bit machines. And it is the standard Python float as well. -Chris In [90]: x = array([1/3],dtype=float32) In [91]: x Out[91]: array([ 0.3334], dtype=float32) In [92]: x = array([1/3],dtype=float64) In [93]: x Out[93]: array([ 0.]) Obviously, the float32 and float64 representations of 1/3 are different, but what is the meaning of float64 on a 32-bit machine? Shouldn't a 32-bit machine only be able represent float32? Thanks! ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Hiring: Software Developer, Scientific Applications
Enthought is hiring a Software Developer. See the description below, or on our website: http://www.enthought.com/company/sd-scientific-app.php Best, Amenity -- Amenity Applewhite Enthought, Inc. Scientific Computing Solutions www.enthought.com Software Developer The Software Developer at Enthought, Inc. participates in the development of scientific and technical applications involving GUIs, 2- D and 3-D graphics, workflow and pipeline architecture, and numerical algorithms. The position also involves some interaction with clients. Some travel may be required. We are interested both in experienced applicants as well as in recent graduates. Applicants should have a BS, MS, or PhD degree with a strong background in science and mathematics, as well as real experience developing quality software, either commercial or open source. More experienced applicants should also have demonstrated project management skills and the ability to lead a team of strong developers with highly technical backgrounds. Applicants will be measured against the following qualifications: • (Required) Bachelor's Degree in Computer Science or other scientific or engineering field with preferably an M.S. or Ph.D. degree. • (Required) Minimum 2 years of technical lead or development experience with 4 or more years preferred. • Ability to understand a problem domain and then conceive of and implement an intuitive user interface geared toward the scientist or engineer user. • Discipline, pride, and professionalism to write readable, documented, and unit-tested code that serves as an example to others who later study your work. • Strong work ethic and commitment to satisfying the customer. • Experience with Python, and a strong understanding of how to apply its capabilities to develop GUI frameworks, work flow frameworks, and elegant scientific applications. • Strong understanding of statistics, optimization, image processing, signal processing, or other technical area. • Experience with the following: • GUI frameworks such as NetBeans or Eclipse • wxPython, Qt • Low-level 2-D graphics APIs such as Quartz or GDI+ • 3-D graphics, preferably using VTK • Developing or working with plotting APIs • Experience using (and interest in contributing to) SciPy • numeric algorithms Enthought offers competitive salaries and the opportunity to work on varied and interesting technical projects. We are located in Austin, TX, consistently rated as one of the best places to live in the US. Benefits include health, dental, vision and a 401k plan. If you are interested in applying, submit a resume to j...@enthought.com. Code samples and links to previous work are encouraged but not required. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] draft release guide
What happens if you try to build a windows installer python setup.py bdist_wininst Also, have you attempted to specify the compiler in $PYTHON_ROOT\Lib\distutils\distutils.cfg ? I've got a script I use to manually change the build section of this file between [build] msvc and [build] mingw32 to switch between default compilers when I've had issues with setup.py. On Wed, Mar 24, 2010 at 2:31 PM, Francesc Alted fal...@pytables.org wrote: A Wednesday 24 March 2010 15:38:58 David Cournapeau escrigué: Oh, it is not that easy :) First, for some reason, the mingw-w64 project does not provide 64 hosted compilers, and since pushing for mingw cross compilation support in distutils would redefine the meaning of insanity, I build my gcc. Since building gcc on windows is not a fun ride either, you have to build it on unix (I have the scripts on my github account: github.com/cournape/). Mmh, not sure about what you mean by hosted compiler, but there is certainly a native compiler package for Win64: mingw-w64-bin_x86_64-mingw_20100322_sezero.zip It comes with gcc, g++ and gfortran 4.4.4. gdb support is also there. So it seems like a pretty complete toolset for windows amd64. With it, and with some fixes in numpy sources (very few), I achieved to pass the build phase. I can provide the patch in case someone is interested. The generated extensions are: 24/03/2010 19:34 1.492.313 multiarray.pyd 24/03/2010 19:34 124.866 multiarray_tests.pyd 24/03/2010 19:34 453.377 scalarmath.pyd 24/03/2010 19:34 1.079.827 umath.pyd 24/03/2010 19:34 121.651 umath_tests.pyd 24/03/2010 19:34 304.014 _sort.pyd which looks good to my eyes. Now, when I try to generate the installable package I'm in trouble again: $ python setup.py bdist [...] File C: \Users\francesc\Desktop\NumPy\1.4.x\numpy\distutils\command\config.py , line 56, in _check_compiler self.compiler.initialize() File C:\Python26_64\lib\distutils\msvc9compiler.py, line 359, in initialize vc_env = query_vcvarsall(VERSION, plat_spec) File C:\Python26_64\lib\distutils\msvc9compiler.py, line 275, in query_vcvar sall raise ValueError(str(list(result.keys( ValueError: [u'path'] [...] So, it looks like either numpy or python cannot determine that the used compiler is mingw instead of msvc9. However, when I try to specify mingw explicitly, I get the next error: $ python setup.py bdist --compiler=mingw32 Running from numpy source directory. Forcing DISTUTILS_USE_SDK=1 usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: option --compiler not recognized Someone could tell me why distutils can be told to use mingw32 compiler for the build stage but not for bdist? What is more, why the need for a compiler for bdist if numpy is already built? I feel that I'm almost there, but some piece still resists... -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Patrick Marsh Ph.D. Student / NSSL Liaison to the HWT School of Meteorology / University of Oklahoma Cooperative Institute for Mesoscale Meteorological Studies National Severe Storms Laboratory http://www.patricktmarsh.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] draft release guide
Francesc Alted wrote: A Wednesday 24 March 2010 15:38:58 David Cournapeau escrigué: Oh, it is not that easy :) First, for some reason, the mingw-w64 project does not provide 64 hosted compilers, and since pushing for mingw cross compilation support in distutils would redefine the meaning of insanity, I build my gcc. Since building gcc on windows is not a fun ride either, you have to build it on unix (I have the scripts on my github account: github.com/cournape/). Mmh, not sure about what you mean by hosted compiler Hosted compiler refers to the platform the compiler itself runs on (so here I mean a native 64 bits compiler, instead of a 32 bits compiler which targets 64 bits). It is nice that mingw-w64 gives a 64 bits hosted, that's recent. It comes with gcc, g++ and gfortran 4.4.4. gdb support is also there. So it seems like a pretty complete toolset for windows amd64. The problem with gdb (but I would need to see if that's still true) is that it did not give useful traceback for code compiled with MS compiler , the stack was always corrupted somewhere for the crashes I encountered. With it, and with some fixes in numpy sources (very few), I achieved to pass the build phase. I can provide the patch in case someone is interested. Building should work out of the box, actually - what are the issues ? which looks good to my eyes. Now, when I try to generate the installable package I'm in trouble again: $ python setup.py bdist [...] File C: \Users\francesc\Desktop\NumPy\1.4.x\numpy\distutils\command\config.py , line 56, in _check_compiler self.compiler.initialize() File C:\Python26_64\lib\distutils\msvc9compiler.py, line 359, in initialize vc_env = query_vcvarsall(VERSION, plat_spec) File C:\Python26_64\lib\distutils\msvc9compiler.py, line 275, in query_vcvar sall raise ValueError(str(list(result.keys( ValueError: [u'path'] [...] So, it looks like either numpy or python cannot determine that the used compiler is mingw instead of msvc9. Yes, you have to set it explicitly, this is no different than on 32 bits: python setup.py build -c mingw32 bdist_wininst. But the main problem is not to build numpy (the 1.3.0 64 bits msi was built with mingw-w64 already) - it is to find out what causes the various crashes people encountered. Some were due to bugs in mingw which have been fixed since then. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
