On Wed, Mar 24, 2010 at 11:35 PM, Nadav Horesh 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

On Wed, Mar 24, 2010 at 09:43, David Cournapeau wrote:

On Wed, Mar 24, 2010 at 11:35 PM, Nadav Horesh 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

On Wed, Mar 24, 2010 at 10:20, Charles R Harris wrote:

On Wed, Mar 24, 2010 at 9:07 AM, Robert Kern wrote:

...

On Wed, Mar 24, 2010 at 09:43, David Cournapeau wrote:

...

On Wed, Mar 24, 2010 at 11:35 PM, Nadav Horesh 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

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

On Wed, Mar 24, 2010 at 9:29 AM, Pauli Virtanen 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

On Wed, Mar 24, 2010 at 09:35, Nadav Horesh 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

On 03/24/2010 01:25 PM, Charles R Harris wrote:

On Wed, Mar 24, 2010 at 8:17 AM, Bruce Southey mailto:bsouthey@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) $ 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__'):

On Wed, Mar 24, 2010 at 12:41 PM, Pauli Virtanen

wrote:

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...

Might be related to this also: http://bugs.python.org/issue7624. I don't see any easy way to get a patch from the python repository for the revision that was to supposed to fix that. Anyone know how to do that? Chuck