Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pyclaw.io name collision with python's io module when running doctest #409

Closed
ketch opened this issue May 28, 2014 · 4 comments
Closed

pyclaw.io name collision with python's io module when running doctest #409

ketch opened this issue May 28, 2014 · 4 comments

Comments

@ketch
Copy link
Member

ketch commented May 28, 2014

Attempting to run doctests in src/pyclaw gives

» python geometry.py
Traceback (most recent call last):
  File "geometry.py", line 771, in <module>
    import doctest
  File "/Users/ketch/anaconda/lib/python2.7/doctest.py", line 99, in <module>
    import unittest, difflib, pdb, tempfile
  File "/Users/ketch/anaconda/lib/python2.7/tempfile.py", line 32, in <module>
    import io as _io
  File "/Users/ketch/Research/Software/clawpack/pyclaw/src/pyclaw/io/__init__.py", line 14, in <module>
    import ascii 
  File "/Users/ketch/Research/Software/clawpack/pyclaw/src/pyclaw/io/ascii.py", line 12, in <module>
    from ..util import read_data_line
ValueError: Attempted relative import beyond toplevel package

I was initially misled by the message about the relative import. The thing is, pyclaw.io shouldn't be involved at all here (this is the geometry module!) Doctest is trying to import the basic python IO module but it picks up the local package called "io" first.

Namespace fail.

This is extremely annoying. One option is to rename our io module, but that seems silly.

@mandli
Copy link
Member

mandli commented Jul 12, 2014

Running nosetests in src/pyclaw

nosetests --first-pkg-wins --with-doctest --exclude=example

seems to avoid this issue.

@ketch ketch added the I/O label Jul 16, 2014
@mandli
Copy link
Member

mandli commented Dec 17, 2014

Should we add this to the travis script then?

@ketch
Copy link
Member Author

ketch commented Dec 18, 2014

I did, here: #405
But there are other issues, which I'm working on.

https://twitter.com/steve_silvester/status/519632438159372288

@ketch
Copy link
Member Author

ketch commented Dec 18, 2014

I'm going to close this since @mandli's workaround seems like the best option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants