Unable to load DLL python module in PyCharm. Works fine in IPython

Question

When I use the IPython included with Enthought Python Distribution, I can import the pyvision package just fine. However, when I try to import pyvision inside of PyCharm 1.2

Answer 1

Add to your PATH environment variable

C:\Python27
C:\Python27\DLLs
C:\Python27\Scripts

Answer 2

I had the same problem. I'm using Winpython32 and trying to import win32com. Worked everywhere (I tried) except in PyCharm. sys.path and os.environ['PYTHONPATH'] had some extra entries inside Pycharm, but nothing is missing compared to when run elsewhere.

The solution was to start Pycharm within the Winpython console and not using the shortcut.

sys.path and os.environ['PYTHONPATH'] did not change. os.environ['PATH'] had several additional entries set, all related to the python installation. At this point I suspect it has to do with "non-standard" installations. Winpython32 tries to be "portable", while other reports of similar problems are when using Enthought or Python(x,y).

Manually adding:

 C:\WinPython-32\python-2.7.6\
 C:\WinPython-32\python-2.7.6\DLLs
 C:\WinPython-32\python-2.7.6\Scripts

to the system path (the global PATH environment variable in Windows) solved the problem without having to run Pycharm within the Winpython command line. Note: C:\WinPython-32\python-2.7.6\Scripts alone did not solve it.

Answer 3

This is a pretty frustrating bug in PyCharm. Even if you set your virtualenv from within PyCharm, the "python console" defaults to the system python. When you installed PyCharm, presumably you used a win32 python on a 64 bit machine.

Go to file>settings>Build, Execution, Deployment>Console>Python Console and change the Python Interpreter from the system version to your virtualenv.

Of course, PyCharm doesn't immediately refresh it. You have to close your project and reopen it.

To verify this was successful, open the Python Console (Tools>Python Console) and check the very first line of the output: it should point to the python.exe of your virtual environment, not the system python.

Answer 4

I apologize for my explanation being long and probably not the best of clarity, but this is the best I could do to describe my experience.

I was having the same problem after first installation and this is how I solved it:

I had noticed there are some settings, as indicated in other answers, that tell pyCharm which interpreters and environment managers to use and I was sure the problem was with setting these options, but I was not sure how, so I started searching.

Setting interpreter

I had more or less followed the standard tutorial, assuming in some point I would have used newly created virtualenv inside my project folder. I was initially getting the DLL error, but as I made sure the interpreter settings were pointing at a valid executable.

Here it is explained how to do this.

Setting environment

at this point the error disappeared, but I had progressed towards a new error. The problem at this point I was not being able to import any module as they were not found. This is because I was working inside the newly created virtualenv, basically a pristine installation, with no modules installed. I am sure there are more evolved solutions (install modules in the virtualenv), but I was just looking for making the code to work, so I set the environment to use my anaconda usual development environment.

For me, with conda on windows (after activating the development environment with conda activate) then (see ..../anaconda-python-where-are-the-virtual-environments-stored for other systems). where python gives the path to the interpreter conda info --envs gives me the existing environment that I want to use.

This fixed everything for me.

Answer 5

I couldn't find the link but I saved this pic - hopefully works for you

Answer 6

I've had that problem before, and it seemed to get fixed by repairing Enthought.

EDIT: I just checked, one of my f2py projects was still suffering from this exact error. Repairing Enthought did not work. The solution to my problem actually lay in fixing the Windows path variable. You need to make sure c:\Python27\Scripts (or your equivalent) is in the path. Furthermore, and this is VERY important, make sure each entry in the global and user path environment variables has NO trailing slashes. This breaks the GNU make utility on Windows.