Trouble importing modules from the same folder

Question

I am having trouble importing a module that I created. This module is in the same folder that the module from which I need to import it is. I am working on a module thats called directo_etapas.py and from there I need to import solvers.py, so I go:

import math
import solvers

I don't get any error while importing math module, but I do get an error with import solvers.

I get this error:

"C:\Users\...\Codigos\directo_etapas.py"
Traceback (most recent call last):
  File   "C:\Users\...\AppData\Local\Enthought\Canopy\App\appdata\canopy-1.5.5.3123.win-x86_64\lib\site-packages\IPython\core\ultratb.py", line 776, in structured_traceback
    records = _fixed_getinnerframes(etb, context, tb_offset)
  File "C:\Users\...\AppData\Local\Enthought\Canopy\App\appdata\canopy-1.5.5.3123.win-x86_64\lib\site-packages\IPython\core\ultratb.py", line 230, in wrapped
    return f(*args, **kwargs)
  File "C:\Users\...\AppData\Local\Enthought\Canopy\App\appdata\canopy-1.5.5.3123.win-x86_64\lib\site-packages\IPython\core\ultratb.py", line 267, in _fixed_getinnerframes
    if rname == '<ipython console>' or rname.endswith('<string>'):
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in position 80: ordinal not in range(128)
ERROR: Internal Python error in the inspect module.
Below is the traceback from this internal error.


**Unfortunately, your original traceback can not be constructed.**

Note that I'm using Enthough Canopy.

Answer 1

The traceback which you see is probably due, as @BorrajaX indicates, to working with a pathname or filename containing non-ASCII characters. (The underlying problem with non-ASCII pathnames is that Python 2 doesn't support unicode consistently, as Python 3 does; successive versions of Canopy handle these better, but still imperfectly.) For now, the simplest solution is to use only ASCII pathnames and filenames.

But if I understand your description, this unicode problem, while real and needing fixing, may be secondary to a different original error. (Note "your original traceback can not be reconstructed" suggesting that the unicode error occurred while trying to report the original error.)

---

Your original error may be as simple as not realizing that in order to import a module, its path must be on python's sys.path. This should always be true of the standard math module, so you can almost always import it any time. But (surprisingly to beginners) it is not in general true of the directory containing the script that you are running. I.e. just because you are running directo_etapas.py doesn't mean that other files (e.g. solvers) in the same directory can be imported.

For the record, the "professional-grade" solutions to this problem are either to create a "python package" (look it up) containing all your related modules, or to "install" your library modules (e.g. solvers) into your python distribution so that they will always be just as accessible as math is. But these are probably more work than you want to do right now.

If this is indeed the source of your original error, then there are two easy ways to make sure that your modules' directory is on sys.path.

a) The simplest, though less robust, is simply to be sure that you are running from that directory, because sys.path usually begins with an empty string, meaning the current directory.

If you are running your scripts within the Canopy GUI, then you can do this with the “Change to Editor directory” or “Keep Directory Synced to Editor” commands as described in the Canopy User Guide section "Change directory". Otherwise, if you are running your scripts from a Windows command prompt, just cd to that directory before running your script.

b) A somewhat more robust solution, for modules that you'll want to be using more broadly but don't yet want the work of installing, is to put their containing paths into the PYTHONPATH environment variable. For more on that, see this article.

(You could also write code to ensure that the desired directory is on sys.path, by looking up the directory that your main script lives in (see __file__), and then either making that the current working directory, or inserting it into sys.path. However those solutions smell a bit hacky.)