I have Blender 2.66a which is an application that offers Python 3.3 APIs, On my system I have an installation of Python 3.2 with several modules that I wish to use inside Blender, I tried both
sys.path.append(r"/usr/lib/python3.2/")
sys.path.append("/usr/lib/python3.2/")
and this commands gives no errors, infact even the autocomplete feature works and new modules are indexed, so i tried
import tkinter
but this generates the following error
Traceback (most recent call last):
File "<blender_console>", line 1, in <module>
File "/usr/lib/python3.2/tkinter/__init__.py", line 42, in <module>
raise ImportError(str(msg) + ', please install the python-tk package')
ImportError: No module named '_tkinter', please install the python-tk package
and I don't get the point of this error because it fails to load a module that it's there asking me to install the same module because that module is not installed ( ? ).
What can cause this obscure problem ?
EDIT
the tkinter module works from the gnome-terminal
If I got you right, you're using Python 3.3 from Blender but try to include the 3.2 standard library. This is bound to give you a flurry of issues, you should not do that. Find another way. It's likely that Blender offers a way to use the 3.3 standard library (and that's 99% compatible with 3.2). Pure-Python third party library can, of course, be included by fiddling with sys.path.
The specific issue you're seeing now is likely caused by the version difference. As people have pointed out in the comments, Python 3.3 doesn't find the _tkinter extension module. Although it is present (as it works from Python 3.2), it is most likely in a .so file with an ABI tag that is incompatible with Blender's Python 3.3, hence it won't even look at it (much like a module.txt is not considered for import module). This is a good thing. Extension modules are highly version-specific, slight ABI mismatches (such as between 3.2 and 3.3, or two 3.3 compiled with different options) can cause pretty much any kind of error, from crashes to memory leaks to silent data corruption or even something completely different.
You can verify whether this is the case via import _tkinter; print(_tkinter.__file__) in the 3.2 shell. Alternatively, _tkinter may live in a different directory entirely. Adding that directory won't actually fix the real issue outlined above.
Related
I'm trying to use pyFirmata, but I can't get it to work. Even the most basic of the library does not work. I guess there is something wrong with the library code.
from pyfirmata import Arduino,util
import time
port = 'COM5'
board = Arduino(port)
I get this error:
Traceback (most recent call last):
File "c:\Users\Public\pythonpublic\arduino.py", line 5, in <module>
board = Arduino(port)
^^^^^^^^^^^^^
File "C:\Users\marce\AppData\Roaming\Python\Python311\site-packages\pyfirmata\__init__.py", line 19, in __init__
super(Arduino, self).__init__(*args, **kwargs)
File "C:\Users\marce\AppData\Roaming\Python\Python311\site-packages\pyfirmata\pyfirmata.py", line 101, in __init__
self.setup_layout(layout)
File "C:\Users\marce\AppData\Roaming\Python\Python311\site-packages\pyfirmata\pyfirmata.py", line 157, in setup_layout
self._set_default_handlers()
File "C:\Users\marce\AppData\Roaming\Python\Python311\site-packages\pyfirmata\pyfirmata.py", line 161, in _set_default_handlers
self.add_cmd_handler(ANALOG_MESSAGE, self._handle_analog_message)
File "C:\Users\marce\AppData\Roaming\Python\Python311\site-packages\pyfirmata\pyfirmata.py", line 185, in add_cmd_handler
len_args = len(inspect.getargspec(func)[0])
^^^^^^^^^^^^^^^^^^
AttributeError: module 'inspect' has no attribute 'getargspec'. Did you mean: 'getargs'?
As already pointed out in another answer, the pyFirmata modules is currently documented to run on Python 2.7, 3.6 and 3.7. This doesn't mean it won't work on other versions, but probably that it hasn't been tested on other versions by the author and it isn't officially supported. So it may or may not work on newer Python versions.
Your error message is caused by a missing function inspect.getargspec(). This function is part of the Python Standard Library, but has been deprecated since Python 3.0 (which came out in 2008). Unfortunately the author wasn't aware of this or simply didn't bother to fix it, so now the code doesn't work anymore with the latest version of Python.
In the Python documentation, you can see that the function is still available in version 3.10, but not in version 3.11.
To solve this you have a number of options:
Downgrade to Python 3.10, which is currently still a good option (Python 3.10 is "alive" until 2026-10-04). I don't know if all other functionality does work. I guess it will, but you would have to find out yourself.
Downgrade to Python 3.7, which is claimed to be supported. Given that Python 3.7 is also still alive (until 2023-06-27), that's a reasonable option as well.
Create an issue for the pyFirmata module and hope the author will fix the problem. Note that an issue has already been created by someone in 2019 but apparently without effect. You could leave a comment there confirming that this has now broken for real.
Clone the library and fix it yourself (and create a Pull Request to get it in the official library).
Find another, similar, library that does work with Python 3.11.
Write the code yourself.
Downgrading to a Python version between 3.7 and 3.10 is certainly the simplest option, and leaving some feedback to the author will give you a chance it will be fixed in the future, in case your planning to use your script for a longer time.
According to the first line of pyFirmata docs:
It runs on Python 2.7, 3.6 and 3.7
You are using Python 3.11. The inspect (core library module) has changed since Python 3.7.
I'm getting the error
Traceback (most recent call last):
File "ghs.py", line 1, in <module>
import stdio
ImportError: No module named stdio
When I try to run my script. I can run my script on other machines just fine. I have installed python using homebrew. And I've tried everything I can think of to get it to recognize my modules! I've uninstalled and reinstalled using brew. I've tried changing the path (though I don't fully understand this). I get no issues using brew doctor.
I've also tried using a python virtual environment but to no avail.
Any ideas on how to fix this issue or else 'start fresh' from a fresh version of python?
When you import a module, Python looks for it at the directory your code is, and the directory in which the built-in libraries are (C:\Users\pc\AppData\Local\Programs\Python\Python35-32\Lib in my case, I'm using Windows 10 and Python 3.5). If it can't find it, it raises ImportError.
I couldn't find a module named stdio in my computer. I also know some C++ and as far as I know, stdio is the library for inputs and outputs(prints). In python, there is no need to import such a library.
You can use try,except statement to test if your code works without importing the module like this.
try:
import stdio
except:
#rest of your code goes here
You will need to indent your whole code however this can be done easily with a text editor in which you can edit more than one line at a time.
I would like to use the following Python package, which requires ncurses: https://pypi.python.org/pypi/blessings
I have the Windows version of Anaconda Python installed, and designated as my Python distribution.
I have also have a Cygwin installation. When I run python -i within the provided Cygwin terminal, Anaconda Python starts up -- great!
If I then try import blessings, I'll get the following error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "A:\anaconda\lib\site-packages\blessings\__init__.py", line 5, in <module>
import curses
File "A:\anaconda\lib\curses\__init__.py", line 15, in <module>
from _curses import *
ImportError: No module named _curses
Alright, so what's happening is that Anaconda Python is understandably not picking up Cygwin's curses.
Now, does it even make sense to try and somehow make Anaconda aware of ncurses, only within the context of usage in a Cygwin terminal? I suspect it isn't, and that I am missing something conceptually?
You won't be able to use Cygwin Python's curses module with CPython unfortunately. Modules for the two Pythons are incompatible for the following reasons (and more):
Windows Python directly calls the Win32 API (via either the Visual Studio 2008, 2010 or 2015 C-Runtimes) while Cygwin Python links to the Cygwin POSIX API which is layered on top of the Visual Studio 6.0 C-Runtime. Mixing different C-Runtimes in a single process is a very bad idea: http://siomsystems.com/mixing-visual-studio-versions/, never mind further abstracted through a POSIX API.
Regardless of the C-Runtime differences, Cygwin implements the LP64 model while Windows implements the LLP64 model which would make the 64-bit size of long different between each, so some structures could be differently sized. They would likely be anyway due to #ifdefs in the code.
Is there any reason you can't use colorama?
The documentation for blessings suggests that should work.
When I import a module I built, I get this boost-python related error:
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: dlopen(./myMod.so, 2): Symbol not found: __ZN5boost6python7objects15function_objectERKNS1_11py_functionERKSt4pairIPKNS0_6detail7keywordES9_E
Referenced from: ./myMod.so
Expected in: flat namespace
in ./myMod.so
What does this actually mean? Why was this error raised?
Description
The problem was caused by mixing objects that compiled with libc++ and object that compiled with libstdc++.
In our case, the library myMod.so (compiled with libstdc++) need boost-python that compiled with libstdc++ (boost-python-libstdc++ from now). When boost-python is boost-python-libstdc++, it will work fine. Otherwise - on computer that its boost-python has compiled with libc++ (or another c++ library), it will have a problem loading and running it.
In our case, it happens because that libc++ developers intentionally changed the name of all of their symbols to prevent you (and save you) from mixing code from their library and code from a different one: myMod.so need a function that take an argument from the type. In libc++, this type's name is std::__1::pair. Therefore, this symbol was not found.
To understand why mixing two version of the same API is bad, consider this situation: There are two libraries: Foo and Bar. They both have a function that takes a std::string and uses it for something but they use a different c++ library. When a std::string that has been created by Foo will be passed to Bar, Bar will think that this is an instance of its c++ library's std::string and then bad things can happen (they are a completely different objects).
Note: In some cases, there would be no problem with two or more different versions of the same API in a completely different parts of a program. There will be a problem if they will pass this API's objects between them. However, checking that can be very hard, especially if they pass the API object only as a member of another object. Also, a library's initialization function can do things that should not happen twice. Another version may do these things again.
How to solve that?
You can always recompile your libraries and make them match each other.
You can link boost-python to your library as a static library. Then, it will work on almost every computer (even one that doesn't has boost-python installed). See more about that here.
Summary
myMod.so need another version of boost-python, one that compiled with a specific c++ library. Therefore, It would not work with any another version.
In my case I was receiving:
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/xmlsec.cpython-38-darwin.so, 0x0002): symbol not found in flat namespace '_xmlSecDSigNs'
BACKGROUND:
M1 MacBook Pro with Montery
I was working with a python virtualenv (using pyenv) to use an earlier version of python3.8 (3.8.2), while my system had 3.8.10 installed natively.
While I was in the activated 3.8.2 virtualenv I noticed the path in dlopen() was pointing to the package in the native python install NOT the virtualenv install.
SOLUTION:
In my case, I did not need the native 3.8 version at all so I simply removed it and this solved the problem.
I encounter the same problem.
Expected in: flat namespace
Add the linker flag fixes the problem
-lboost_python37
change the dynamic library name to the one installed on the os.
By the way, my os is macOS High Sierra and I use brew to install boost_python3.
Symbol not found means the definition of the declared function or variable was not found. When a header file of a shared object is compiled with your program, linker adds symbols of declared functions and objects to your compiled program. When your program is loaded by the OS's loader, the symbols are resolved so that their definition will be loaded. It is only at this time where if the implementation is missing, loader complains it couldn't find the definition due to may be failing to resolve the actual path to the library or the library itself wasn't compiled with the implementation/source file where the definition of the function or object resides. There is a good article on this on the linux journal http://www.linuxjournal.com/article/6463.
In my case I was just failing to import all the required sources (c++ files) when compiling with Cython.
From the string after "Symbol not found" you can understand which library you are missing.
One of the solutions I found was to uninstall and reinstall it using the no-binary flag, which forces pip to compile the module from source instead of installing from precompiled wheel.
pip install --no-binary :all: <name-of-module>
Found this solution here
Here's what I've learned (osx):
If this is supposed to work (i.e. it works on another computer), you may be experiencing clang/gcc issues. To debug this, use otool -l on the .so file which is raising the error, or a suspect library (in my example it's a boost-python dylib file) and examine the contents. Anything in the /System/ folder is built with clang, and should be installed somewhere else with the gcc compiler. Never delete anything in the /System folder.
.so files are dynamic libraries (so = shared object). On Windows they are called .dll (dynamic-link library). They contain compiled code which contains functions available for usage to any executable which links them.
What is important to notice here is that those .so are not Python files. They were probably compiled from C or C++ code and contain public functions which can be used from Python code (see documentation on Extending Python with C or C++).
On your case, well, you have a corrupt .so. Try reinstalling the affected libraries, or Python, or both.
Problem
I had this same issue when running puma as part of Rails app
LoadError:
dlopen(/Users/alucard/.rbenv/versions/2.7.6/lib/ruby/gems/2.7.0/gems/puma-5.6.4/lib/puma/puma_http11.bundle, 0x0009): symbol not found in flat namespace '_ERR_load_crypto_strings'
/Users/alucard/.rbenv/versions/2.7.6/lib/ruby/gems/2.7.0/gems/puma-5.6.4/lib/puma/puma_http11.bundle
Solution
It was solved just by installing puma gem again gem install puma
I wrote
import serial
There message are occured.
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/site-packages/serial/__init__.py", line 20, in ?
from serialposix import *
File "/usr/lib/python2.4/site-packages/serial/serialposix.py", line 13, in ?
import sys, os, fcntl, termios, struct, select, errno
ImportError: No module named termios
What's wrong?
termios has been in the Python standard library since 2.0 at least (I'm not very familiar with older Python versions), but it's always been a Unix-only module. Your 2.4 should be fine, IF you're running under any Unix flavor -- i.e., anything but Windows, more or less. The problem you're seeing suggests either a faulty Python install, or that you're on a non-Unix platform (and if it's not Windows I'm very curious to learn what it IS).
Edit: OP has clarified that they're on Debian -- which has a long history of removing some crucial pieces from upstream components and hiding them in hard-to-locate packages, a history that has long hurt their Python packaging in particular.
I tried several package search engines but I can't find out where they hid termios for Python in particular (for any version) so all I can suggest are workarounds (unless the debian tag I just added attracts debian experts who can help) as well of course as asking on debian-specific forums (clarifying exactly what versions are in use, of course).
Maybe installing another Python (a REAL Python, not the "cleverly packaged", i.e. mangled into pieces and with pieces missing, Debian travesty) might help -- for example, if both sticking with Python 2.4 and using .deb are important constraints to the OP, PYTHON2.4_2.4.6-1UBUNTU3_I386.DEB (not sure how cleanly it and its dependencies install on the OP's specific Debian version, of course); or else, one might as well go with a more recent and complete Python, see for example here (specifically for Debian Etch, but hopefully it can be adapted for the OP's exact version).