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).
Related
When doing
import dbm.gnu
on a standard Python 3.7.6 (64) for Windows, I get:
File "C:\Python37\lib\dbm\gnu.py", line 3, in
from _gdbm import *
ModuleNotFoundError: No module named '_gdbm'
Isn't dbm.gnu supported out of the box on Windows?
The same problem happens with:
import dbm.ndbm
File "C:\Python37\lib\dbm\ndbm.py", line 3, in
from _dbm import *
ModuleNotFoundError: No module named '_dbm'
I tested on another Python 3.6.8, and it's the same.
This has always been the case (that gdbm and ndbm are not supported on windows). See also issue 3769 for background and dbm and windows, and issue 3783 for something to work on if you want to contribute to making the dbm story on windows better.
Googling found a gdbm port to windows, so if you are trying to use source files from linux, that might help you. We're open to suggestions on improving the situation here, but someone has to figure out what would make sense and champion it. Bundling the gdbm windows port is probably not an option, but making it possible to install something via PIP that will work is, if there's anything in core preventing that currently.
I have a question about runtime error.
#!/usr/bin/env python3
import hebi
from time import sleep
lookup = hebi.Lookup()
At lookup = hebi.Lookup(), the error below happened.
Traceback (most recent call last):
File "hello.py", line 1, in <module>
import hebi
.....
File "C:\Users\AppData\Local\Programs\Python\Python37-32\lib\site-packages\hebi\_internal\raw.py", line 394,
in _init_hebi_library
raise RuntimeError('HEBI Core library not found')
RuntimeError: HEBI Core library not found
I'm not sure why HEBI Core is not there. How and where do I install some tools for solving this problem?
Sorry about the issues that you are having.
I maintain the Python API at HEBI, and I am aware of this issue (although I just saw this issue now).
A solution to this is coming soon, but for the time being, please download and install the 64 bit version of Python 3 from Python's website ( https://www.python.org/downloads/windows/ ) or see the temporary workaround below. Please also note that the 64 bit version is the x86-64 version - NOT x86.
If you require the 32 bit Python (or just do not want to install the 64 bit version for whatever reason), you can replace the file at
C:\Users\AppData\Local\Programs\Python\Python37-32\lib\site-packages\hebi\lib\win_x64\hebi.dll
with the file at
C:\Users\AppData\Local\Programs\Python\Python37-32\lib\site-packages\hebi\lib\win_x86\hebi.dll
However, realize that you will not be able to run the API with a 64 bit Python executable this way.
If you are at all curious what is happening here, the (currently) faulty logic is attempting to load hebi.dll but fails to since it tries to load the x86-64 version and not the 32 bit (x86) version.
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.
I am a programming novice, so apologize in advance if I'm asking a dumb question or perpetrating some site etiquette violation. I have tried very hard to research the answer to my question on an issue that seems to be very common, but none of the proposed solutions have worked, so am looking for some help as I just don't know what to try next.
I'm trying to import Panda from iPython onto Windows 8. I have version 2.7 of Python and have successfully downloaded Numpy. Given the suggestions on this site, I have downloaded all the file that I think Panda is dependent on (pytx, dateutil, setuptools), but it still didn't work: the error message includes:
Import Error Traceback (most recent call)
<ipython-input-2-d6ac987968b6> in <module>()
try
from.import hashtable, tslib, lib
except exception: # pragma: no cover
import datetime
- C: \Python27\lib\site-packages\pandas\__init__.py in <module>():
Import Error: No module named six
Out of desperation, I also deleted all previous version of pandas and loaded Aneconda, thinking from previous responses that might help capture all required modules including Pandas, but the same error keeps coming up.
Any help would be much appreciated, and don't worry about pointing out the obvious (since it's clearly not obvious to me.)
The easiest way to get modules up and running on Windows is to use Christoph Gohlke's Python Extension Packages for Windows repository. It includes installers for a ton of (mainly scientific-related) modules, including pandas, matplotlib, six, etc. Since many modules included compiled extensions, installing using pip doesn't always work if the package maintainer hasn't published a binary for your package of interest. Gohlke's packages include everything already pre-compiled, you just need to choose the version and bit-ness of Python, and download the .exe files.
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.