I am getting an assembly error in my code using in a .dll file. This is a template code from another thread, and a lot of people claimed that it worked.
import clr
import os
file = 'CPUThermometerLib.dll'
print('Does this filepath exist?',os.path.isfile(file))
clr.AddReference(file)
There is no problem with the file path I guess since it return true on the .isfile function. Here is the output that I'm getting:
Does this filepath exist? True
File "<stdin>", line 1, in <module>
System.IO.FileNotFoundException: Unable to find assembly 'CPUThermometerLib.dll'.
at Python.Runtime.CLRModule.AddReference(String name)
I have checked multiple threads and none of them is giving a solution. I am using Windows 10, and moreover, my .NET framework version is '4.0.30319.42000'. My laptop processor is an Atom Z3537F.
The clr module is not installed by default on the Windows python installation. You will need to run pip install clr at a prompt to have it added and then your code will be able to import it properly.
You need to provide the full path to the dll file, not just the file name.
If the dll file is in the same directory as your Python script, you can get the full path by using os.path.abspath('CPUThermometerLib.dll').
Full code:
import clr
import os
file = 'CPUThermometerLib.dll'
print('Does this filepath exist?', os.path.isfile(file))
clr.AddReference(os.path.abspath(file))
Related
I am in need of some help with the below. Using Python 3 code on Windows 10. Written in Spyder over Anaconda install and custom environment.
I have some code that runs in Spyder but not Anaconda Prompt. It gets a ModuleNotFoundError. The directory/file structure is like this:
my_python
smb_bau
etl
init.py
etl_globals.py
init.py
my_config.conf
my_connections.py
my_definitions.py
init.py
(underscores round init not displaying for some reason)
Some notes before the problematic code:
It's just test code for now that will be replaced with the real hive code later.
The code works when all the files are in one foler.
Th my_ prefixes are just to avoid any word that might cause issues while testing.
In my_connections I have this code:
class hive_connection:
def __init__(self):
self.my_name = None
self.my_town = None
import configparser
from smb_bau.my_definitions import CONFIG_PATH
config = configparser.ConfigParser()
config.read(CONFIG_PATH)
my_details = config["my_details"]
self.my_name = my_details["my_name"]
self.my_town = my_details["my_town"]
And this is what's in my_definitions:
import os
ROOT_DIR = os.path.dirname(os.path.abspath(__file__))
CONFIG_PATH = os.path.join(ROOT_DIR, 'my_config.conf')
(I gratefully stole this from another thread to solve the issue of getting config info from a different folder).
The file I run is etl_globals which contains this code:
from smb_bau.my_connections import hive_connection
hive = hive_connection()
print(hive.my_name, hive.my_town)
When I run etl_globals in Spyder it works perfectly. But it fails in Anaconda Prompt.
I open up Anaconda Prompt, activate my environment, navigate to the etl folder, and enter python etl_globals.py
The error message I get is:
Traceback (most recent call last):
File "etl_globals.py", line 1, in
from smb_bau.my_connections import hive_connection
ModuleNotFoundError: No module named 'smb_bau'
I don't understand why the import of modules works in Spyder but not Anaconda Prompt.
The overarching goal is to be able to not have all the files in one folder.
Any help would be gratefully appreciated.
Many thanks.
Edit:
Just to be sure what the issue is I simplified it to create a file called my_functions (in the smb_bau folder) with this in:
def fn_test():
print(5)
And a file in the etl folder called my_test with this in:
from smb_bau.my_functions import fn_test
fn_test()
And got the same error:
Traceback (most recent call last):
File "my_test.py", line 1, in
from smb_bau.my_functions import fn_test
ModuleNotFoundError: No module named 'smb_bau'
Why does from smb_bau.my_functions import xxx work in Spyder but not Anaconda prompt?
Also, this may be relevant: the only reason there is a folder called my_python at the top is that I was getting an error saying no module named smb_bau. So I moved it all down a level and then it would accept smb_bau as a module but only in Spyder).
I also just checked PYTHONPATH and the root folder is there.
I have only been using Python for a week so I'm sure there are other bit of my code that aren't great -- but it does work in the spyder client.
Thanks and sorry if any of this is unclear.
I am trying to import a module from the prgoram called 'Power factory" in Python. The folder where power factory file located looks as follow:
I have written a script to import the powerfactory module as follow:
import sys
sys.path.append("PAth of folder")
import powerfactory as pf
When I ran the above code, it throws the following error:
ImportError: DLL load failed while importing powerfactory: The specified module could not be found.
I copied the .dll file present in the power factory folder into the Python DLL folder but no luck. Could anyone help me where am I making the mistake?
Searching the net I found this (from here)
I am not able to import powerfactory module: DLL load failed Category:
Scripting
If an error message appears when importing the powerfactory module
stating “ DLL load failed: the specified module could not be found”,
this means that Microsoft Visual C++ Redistributable for Visual Studio
2012 package is not installed on the computer.
To overcome this problem the user should add the PowerFactory
installation directory to the os path variable within his python
script.
import os
os.environ["PATH"] = r'C:\Program Files\DIgSILENT\PowerFactory 2016;' + os.environ["PATH"]
Copy the .dll file from your digsilent folder, eg. Program Files\DIgSILENT\PowerFactory 2020 SP2A\Python\3.8\boost_python38-vc141-mt-x64-1_68.dll
and place the .dll file directly in your system!
Save it to your C:\Windows\System32 folder.
&
Save it also to your C:\Windows\SysWOW64 folder.
You should be good to go.
I am having issues getting python to import the _analog_swig gnuradio module in order to run gnuradio code on a Windows 8.1 64bit machine.
Some background: I am running Python 2.7.10 (installed in C:\Python27) and have installed the latest gnuradio binary (v3.7.11.1/v1.3 64-Bit Any CPU) from here: http://www.gcndevelopment.com/gnuradio/downloads.htm. I have installed gnuradio to C:\Program Files\GNURadio-3.7 .
I can run gnuradio companion and run flowgraphs from GRC successfully (which calls "C:\Program Files\GNURadio-3.7\bin\run_gr.bat" gnuradio-companion.py).
I have added & verified the following system variables are set:
Path: C:\Program Files\GNURadio-3.7\bin
PYTHONPATH: C:\Program Files\GNURadio-3.7\lib\site-packages
GRC_BLOCKS_PATH: C:\Program Files\GNURadio-3.7\share\gnuradio\grc\blocks
Now to the problem: If I run e.g. CMD and type:
python C:\test\top_block.py
I am returned the following ImportError:
File "C:\test\top_block.py", line 22, in <module>
from gnuradio import analog
File "C:\Program Files\GNURadio-3.7\lib\site-packages\gnuradio\analog\__init__.py", line 33, in <module>
from analog_swig import *
File "C:\Program Files\GNURadio-3.7\lib\site-packages\gnuradio\analog\analog_swig.py", line 17, in <module>
_analog_swig = swig_import_helper()
File "C:\Program Files\GNURadio-3.7\lib\site-packages\gnuradio\analog\analog_swig.py", line 16, in swig_import_helper
return importlib.import_module('_analog_swig')
File "C:\Python27\lib\importlib\__init__.py", line 37, in import_module
__import__(name)
ImportError: No module named _analog_swig
The folder content of C:\Program Files\GNURadio-3.7\lib\site-packages\gnuradio\analog is as follows:
Comparing this to the folder content on a linux machine, which has a working install of gnuradio that works with python as I want it:
The difference seems to be that the folder in windows contains only a _analog_swig.pyc file, whereas the folder in linux contains a _analog_swig_.so file.
Any idea why the _analog_swig module can apparently not be imported in windows?
My plan is to be able to run gnuradio code directly from my python interpreter and being able to create compiled gnuradio executables so any help on how this could be fixed is much appreciated.
I've been struggling with this for the past few days, but I finally figured it out. I was trying to run GnuRadio Companion generated code in IDLE and also in PyCharm. I kept failing miserably with this same error. I finally figured it out:
-As Flexo says, the PYD file (_analog_swig.pyd) is actually a Windows DLL. The error makes it sound like Python is not finding that file, but that is not at all what was happening. The PYD file, being a DLL, has dependencies itself. Python is able to find _analog_swig.pyd just fine, but it could not find the DEPENDENCIES of that library.
-To verify if that's what wrong in your installation, download and use DependencyWalker (Google it) to check if your system can find the dependencies to _analog_swig.pyd.
-The fix for me was to add the GnuRadio-3.7/bin folder to my PATH environment variable. Inside that folder are a number of DLLs that the _analog_swig.pyd library needs to load. If you don't have the folder in your PATH, the module will fail to load in Python and throw the error you see above.
-I see that you verified that this folder is in your PATH, so this is apparently not the same problem, although your symptoms are exactly the same as mine. i.e. the GRC code would run just fine when you start with "run_gr.bat", but not when you run from a normal CMD window.
Hopefully that helps someone else that wants to use GNURadio Python code on Windows.
Friend,
As you mentioned, the GNU Companion calls \bin\run_gr.bat gnuradio-companion.py. That batch script does quite a bit of work on windows environment variables (try opening it in a text editor if you're curious).
In a sense, the run_gr.bat script puts together a temporary, custom python workspace for gnuradio so it can import anything it needs. It receives python scripts to run in this environment as command line arguments; hence, you can use it to run any GNU radio python code you want in your windows command prompt. Generally, you would call
<gnuradio_install_path>\bin\run_gr.bat <gnu_radio_code>.py
To test your import, you can try
# test.py
from gnuradio import analog
try calling the following from the command prompt, in the test.py directory:
<gnuradio_install_path>\bin\run_gr.bat test.py
Im trying to compile Godot engine following the instructions here
When I run scons bin/godot as the tutorial says, I get the following error:
scons: Reading SConscript files ...
ImportError: cannot import name _args_from_interpreter_flags:
File "/home/grayfox/github/godot2/godot/SConstruct", line 9:
import multiprocessing
File "/usr/lib64/python2.7/multiprocessing/__init__.py", line 65:
from multiprocessing.util import SUBDEBUG, SUBWARNING
File "/usr/lib64/python2.7/multiprocessing/util.py", line 40:
from subprocess import _args_from_interpreter_flags
The SConstruct file starts this way:
EnsureSConsVersion(0,14);
import string
import os
import os.path
import glob
import sys
import methods
import multiprocessing
...
If I try to run python SConstruct I get an error complaining about missing functions defined by scons (i.e. the script fails after doing all the imports).
Commenting import multiprocessing fixes the issue but I don't want to modify that file, as I would have to revert the change if I ever make a pull request. The project is quite active so I believe this has something to do with my local configuration.
Any ideas why the script is failing to import _args_from_interpreter_flags only if I execute it via scons?
[UPDATE]
I did a fresh Gentoo install and the problem persists. I did some tests and I found this:
In a python terminal>
>>> import SCons.Script
>>> from subprocess import _args_from_interpreter_flags
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: cannot import name _args_from_interpreter_flags
>>> import subprocess
>>> subprocess.__file__
'/usr/lib64/python2.7/site-packages/SCons/compat/_scons_subprocess.pyc'
But the output is different if I do this:
>>> import subprocess
>>> subprocess.__file__
'/usr/lib64/python2.7/subprocess.pyc'
So I update my question: Is this a bug? Can anybody reproduce it in other distros? If it's a bug, should I report it to Gentoo or to SCons?
[ANOTHER UPDATE]
Adding temp.extend([os.path.join(x, 'lib64') for x in prefs]) did't work, same error.
Adding print sys.path at the beginning of the compact module gives:
['/usr/lib64/python-exec/python2.7/scons-local-2.3.0',
'/usr/lib64/python-exec/python2.7/scons-local',
'/usr/lib64/python2.7/site-packages/lib32/scons-2.3.0',
'/usr/lib32/scons-2.3.0',
'/usr/local/lib32/scons-2.3.0',
'/usr/lib64/python2.7/site-packages/lib/python2.7/site-packages/scons-2.3.0',
'/usr/lib/python2.7/site-packages/scons-2.3.0',
'/usr/local/lib/python2.7/site-packages/scons-2.3.0',
'/usr/lib64/scons-2.3.0',
'/usr/lib64/python2.7/site-packages/lib32/scons',
'/usr/lib32/scons',
'/usr/local/lib32/scons',
'/usr/lib64/python2.7/site-packages/lib/python2.7/site-packages/scons',
'/usr/lib/python2.7/site-packages/scons',
'/usr/local/lib/python2.7/site-packages/scons',
'/usr/lib64/scons',
'/usr/lib64/python2.7/site-packages/RBTools-0.6-py2.7.egg',
'/usr/lib64/python27.zip',
'/usr/lib64/python2.7', #It's here, so what's the problem?
'/usr/lib64/python2.7/plat-linux2',
'/usr/lib64/python2.7/lib-tk',
'/usr/lib64/python2.7/lib-old',
'/usr/lib64/python2.7/lib-dynload',
'/usr/lib64/python2.7/site-packages',
'/usr/lib64/python2.7/site-packages/gtk-2.0',
'/usr/lib64/python2.7/site-packages/wx-2.8-gtk2-unicode']
It looks as if this isn't really a problem connected to SCons directly. You might have an alien "subprocess" module/package installed in your system. Also check out Cannot import name _args_from_interpreter_flags which seems to be related.
Based on your updated question: I tried to compile Godot on my machine (Python 2.7.3, SCons 2.3.1, Ubuntu 12.04 LTS) and it's running fine, so the problem is not related to the provided SConstruct (and its supporting build description files in subfolders). The "_scons_subprocess" module gets used only when the import of the original "subprocess.py" fails. So I suspect that the SCons start script sets up a wrong sys.path, which may happen under 64bit (see issue http://scons.tigris.org/issues/show_bug.cgi?id=2657 ).
After you added "temp.extend([os.path.join(x, 'lib64') for x in prefs])", your "print sys.path" statement shows paths like "/usr/lib64/python-exec" in its output. A Google search turned up the page http://forums.gentoo.org/viewtopic-t-985402-start-0.html for me. It describes an issue with Gentoo, where programs are installed as links to pip. Please follow the given advice and see if this fixes your problem.
It's a bug in Gentoo's scons-2.3.0 and scons-2.3.1 ebuilds (see bug report). It has been fixed in versions 2.3.1-r1 and higher.
UPDATE 10 Secs later
Fixed properly now, and thanks to JF and Gauden.
UPDATE
I have found a temporary fix by saving the IDLE file in the directory the other working file is in. (I would still like to know how to fix it entirely if I can.)
That's not a permanant fix, so if you want to try and help make it work wherever the file is saved, feel free.
This is the start of a python file:
#!/usr/bin/python
# -*- coding: utf-8 -*-
import wikipedia
import pagegenerators
import sys
import re
import pywikibot
from pywikibot import *
(You may have noticed it's a pywikipedia script, but I think that's irrelevent)
This file runs fine from the command line.
However, when I try and use IDLE to develop the script, or just use the IDLE interpreter, I get an error:
>>> import wikipedia
Traceback (most recent call last):
File "<pyshell#9>", line 1, in <module>
import wikipedia
ImportError: No module named wikipedia
I don't really have a clue why it isn't working.
I have also tried this:
>>> imp.find_module("wikipedia.py","f:/ake/pa/th/")
Traceback (most recent call last):
File "<pyshell#7>", line 1, in <module>
imp.find_module("wikipedia.py","f:/ake/pa/th/")
ImportError: No frozen submodule named f:/ake/pa/th/.wikipedia.py
The path given in the error log is the correct path to the wikipedia.py file, there's just that . before wikipedia.py.
I then tried adding the path to sys.path, but that didn't work either:
>>> import sys
>>> sys.path.append("c/users/adam/py")
#the same error...
Path to the module: `c:\users\joe_bloggs\py\wikipedia.pyc
Python executable: Command line:C:\Python27\python.exe, IDLE: C:\Python27\pythonw.exe
PYTHONPATH throws, in both:
Traceback (most recent call last):
File "<pyshell#20>", line 1, in <module>
print os.environ['PYTHONPATH'].split(os.pathsep)
File "C:\Python27\lib\os.py", line 423, in __getitem__
return self.data[key.upper()]
KeyError: 'PYTHONPATH'
OS: Windows 7
Python version: 2.7.2
A new PATH: IDLE, and Command Line:
C:\Program Files\Common Files\Microsoft Shared\Windows Live
C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live
C://Python27
C:\Program Files (x86)\IVI Foundation\VISA\WinNT\Bin
C:\Program Files (x86)\QuickTime\QTSystem\
C:\Program Files (x86)\Windows Live\Shared
EDIT The answer to the above question proved to be fairly simple, but I am editing this answer as a possible troubleshooting checklist for future reference, and as a checklist for others who may need to prepare questions of this nature in the future.
CLUE 1: What is the path to the module you are importing?
>>> import wikipedia
>>> print wikipedia.__file__
This will give you the path to the compiled module, and is one clue.
CLUE 2: What is the path to the Python executable?
(See also this question).
>>> import sys
>>> print sys.executable
Try this in the shell and in an IDLE script. If the two results are different, then you are using two Python interpreters and only one of them has a path that points to the wikipedia module.
CLUE 3: What is the sys.path?
Also repeat this in both shell and as a script in IDLE.
>>> print '\n'.join( sys.path )
(You may be able to use sys.path.append("d:/irectory/folder/is/in") to add that location to the sys.path. This should add that directory to the list of places Python looks for modules.)
CLUE 4: What is the PYTHONPATH and does it differ in the two environments?
(See also this answer).
Finally repeat this in both shell and as a script in IDLE.
>>> import os
>>> print '\n'.join( os.environ['PATH'].split(os.pathsep) )
Again note the two results (from shell and from IDLE) and see if there is difference in the PYTHONPATH in the two environments.
If all these tests prove inconclusive, I would add as much of this information as you can to your question as it would help give you specific further leads. Also add what OS you are using and any tracebacks that you get.
I had the same problem when trying to import a newly installed library on my Raspberry Pi. I followed all the instructions to install the library (Adafruit RHT Sensor) and it worked fine from the terminal. However, I couldn't get it to work from within IDLE.
It turned out that the problem was that the Raspberry Pi has both Python 2 and 3 installed. The install I'd done (using the 'python' command) only applied to Python 2. I had to perform another install using the 'python3' command to install it for Python 3. After that, I restarted IDLE and all worked fine.
The suggestion above to print the sys executable path helped point out the discrepancy:
import sys
print sys.executable