I looked through the other posts and bug reports and couldn't figure out what's causing this. I'm using Jython 2.5.1, in a Java project in Eclipse (Ubuntu 8.10). It has been added to the project as a standalone .jar file (I just replaced the old Jython 2.1 jar with this one).
I'm running a script that uses the threading.py class. At some point the statement "import os" is evaluated from linecache.py and I get this error, which I can't seem to figure out how to fix:
'Execution failed. Traceback (most recent call last):
File "<string>", line 1, in <module>
File "../lib/python/threading.py", line 6, in <module>
import traceback
File "../lib/python/traceback.py", line 3, in <module>
import linecache
File "../lib/python/linecache.py", line 9, in <module>
import os
ImportError: No module named os'
What do you mean with "the jar that comes with the 2.5 download"? Did you extract the contents and use jython.jar or did you run the installer? If you just extracted and didn't run the installer your jython.jar will miss the whole LIB folder.
Can you check if jython.jar contains a LIB folder? (e.g. open jython.jar with 7z or WinZip).
Or try copying the LIB folder in the same folder where jython.jar resides.
Did you try setting these properties. Jython Registry. e.g. via -Dpython.home in the eclipse run configuration.
python.cachedir
python.path
python.home
How is the jar named? If similar to jython-complete.jar try renaming it to jython.jar
Something is wrong at a very deep level, but it's probably easy to fix. You are seeing an error that happens while trying to report some other error.
Probably you have your PYTHONPATH misconfigured. I don't know the details of Jython or Eclipse running Jython, but it looks like you have no standard library available to you.
If you are getting maven, using the dependency jython-standalone instead of jython may help (at least it did for me in a maven project with jython-standalone-2.5.3)
Related
I would like to have an interface between Python and sqlite. Both are installed on the machine. I had an old version of Python (2.4.3). So, pysqlite was not included by default. First, I tried to solve this problem by installing pysqlite but I did not succeed in this direction. My second attempt to solve the problem was to install a new version of Python. I do not have the root permissions on the machine. So, I installed it locally. The new version of Python is (2.6.2). As far as I know this version should contain pysqlite by default (and now it is called "sqlite3", not "pysqlite2", as before).
However, if I type:
from sqlite3 import *
I get:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/verrtex/opt/lib/python2.6/sqlite3/__init__.py", line 24, in <module>
from dbapi2 import *
File "/home/verrtex/opt/lib/python2.6/sqlite3/dbapi2.py", line 27, in <module>
from _sqlite3 import *
ImportError: No module named _sqlite3
It has to be noted, that the above error message is different from those which I get if I type "from blablabla import *":
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named blablabla
So, python see something related with pysqlite but still has some problems. Can anybody help me, pleas, with that issue?
P.S.
I use CentOS release 5.3 (Final).
On Windows, _sqlite3.pyd resides in C:\Python26\DLLs. On *nix, it should be under a path similar to /usr/lib/python2.6/lib-dynload/_sqlite3.so. Chances are that either you are missing that shared library or your PYTHONPATH is set up incorrectly.
Since you said you did not install as a superuser, it's probably a malformed path; you can manually have Python search a path for _sqlite3.so by doing
import sys
sys.path.append("/path/to/my/libs")
but the preferred approach would probably be to change PYTHONPATH in your .bashrc or other login file.
You have a "slite3.py" (actually its equivalent for a package, sqlite3/__init__.py, so import sqlite3 per se is fine, BUT that module in turns tries to import _sqlite3 and fails, so it's not finding _sqlite3.so. It should be in python2.6/lib-dynload under your local Python root, AND ld should be instructed that it has permission to load dynamic libraries from that directory as well (typically by setting appropriate environment variables e.g. in your .bashrc). Do you have that lib-dynload directory? What's in it? What environment variables do you have which contain the string LD (uppercase), i.e. env|grep LD at your shell prompt?
I am trying to import the spherical harmonic toolbox (SHTOOLS) in python. I have the files downloaded and unzipped and am using RedHat.
I added the package's path to my python system path and when I go to import the package, I get this error:
>>import pyshtools
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "pyshtools/__init__.py", line 49, in <module>
load_documentation()
File "pyshtools/__init__.py", line 27, in load_documentation
from . import _SHTOOLS
ImportError: cannot import name _SHTOOLS
I can not seem to figure out what the issue is. I checked that the path to this folder was actually added to the system path and it was.
Is this an issue on my end? Or is it possible that I have something downloaded incorrectly? If so, how would I go about fixing this issue?
The SHTOOLS package needs to be built with make first to compile the Fortran libraries. The wiki on Github gives directions on which libraries are required - libblas-dev, liblapack-dev, g++, gfortran, and libfftw3-dev (these are the Ubuntu packages, they may have slightly different names on Redhat). Once these are installed, you need to run make, then sudo make all to install the Fortran and Python components. The Makefile has a lot of good comments in it, I'd recommend reading through it before running make.
OK, trying to track down this issue of running a Python package.
Running on Windows.
Only one version of Python is installed on the computer: 3.4.3
Package has been installed (package name: Willie) (details of installation are more convoluted than usual; can provide steps if necessary)
Package installed at: C:\Python34\Lib\site-packages\willie
Startup script is: C:\Python34\Scripts\willie.py
Error is one of the first lines of the script:
from willie.tools import stderr
If I run willie.py from the command line, I get this error:
Traceback (most recent call last):
File "<frozen importlib._bootstrap>", line 2218, in _find_and_load_unlocked
AttributeError: 'module' object has no attribute '__path__'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Python34\Scripts\willie.py", line 15, in <module>
from willie.tools import stderr
File "C:\Python34\Scripts\willie.py", line 15, in <module>
from willie.tools import stderr
ImportError: No module named 'willie.tools'; 'willie' is not a package
The __path__ attribute is supposed to be set automatically when the import function is used, but it doesn't exist, which leads to the program being unable to execute.
C:\Python34\Scripts; is in my Path environment variable.
PYTHONPATH has been set for everything from C:\Python34; to C:\Python34;C:\Python34\Lib;C:\Python34\Lib\site-packages;C:\Python34\Lib\site-packages;C:\Python34\Lib\site-packages\willie;C:\Python34\Lib\site-packages\willie\tools;.
In all cases with these directories, if I try to execute the above import command from the interactive Python prompt, it runs correctly. I can use the stderr function, and examine its __file__ and __path__ fields.
If I add C:\Python34\Scripts; to PYTHONPATH, however, I get the same error as using it from the command line: __path__ doesn't exist, 'willie' is not a package.
I do know that willie.py is being called recursively, somehow, because I can add a print() at the top of the file that runs twice.
Looking for help in figuring out how to make this run. Is almost certainly a configuration issue on my end, but I have no idea what to do to fix it.
First, you absolutely do not want c:\Python34\Scripts in your PYTHONPATH. Files under \Scripts are NOT meant to be importable.
Second, willie does some screwing around to make sure willie.py gets installed to c:\Python34\Scripts\willie (note there is no .py suffix). This is decidedly nonstandard. The only reason this even works is because on Unix machines, the first line of that file is a special "shebang" that tells the Unix program launcher to execute the file using Python. There is no equivalent feature on Windows - naming the file willie with no .py means you simply can't execute it.
So it looks like the module willie is simply not prepared to be installed on Windows systems. (#811 and #822 both refer to weirdness on Windows caused by the nonstandard package setup.)
A standard package setup would have willie.py inside the willie package as willie/main.py and, in the package's setup.py, register willie.main as an "Entry Point" named willie. This incantation would create c:\Python34\Scripts\willie.exe on Windows systems when the package is installed using pip.
I believe the reason for the recursive import is because the second entry in sys.path is the name of the script that is run from the command line. So, it's always finding C:\Python34\Scripts\willie.py when it looks for the module willie which is not the one it needs.
As a workaround, you could try renaming C:\Python34\Scripts\willie.py to C:\Python34\Scripts\run-willie.py
I want to make the python script into Windows executable with py2exe. I did not miss MSVCP90.dll and the Feiwings.py(the file that I use for transforming) and setup.py are under the same path. Doing those things under command window, everything works fine, the last lines of the traceback here are:
**binary dependencies****
your executable(s) also depend on these dlls which are not included. You may or may not need to distribute them.
Make sure you have the license if you distribute any of them, and make sure you don't distribute files belonging to the operating system.
USER32.dll -C:\WINDOWS\system32\USER32.dll
SHELL32.dll -C:\WINDOWS\system32\SHELL32.dll
ADVAPI32.dll -C:\WINDOWS\system32\ADVAPI32.dll
WS2_32.dll -C:\WINDOWS\system32\WS2_32.dll
GDI32.dll -C:\WINDOWS\system32\GDI32.dll
KERNEL32.dll -C:\WINDOWS\system32\KERNEL32.dll
The setup.py has the content like this:
from distutils.core import setup
import py2exe
setup(console=['D:\python\Feiwings.py'])
When I cd the path to dist directory, it got an error.
Traceback (most recent call last):
File "Feiwings.py", line 2, in <module>
File "PySide\__init__.pyc", line 45, in <module>
File "PySide\__init__.pyc", line 43, in _setupQtDirectories
UnboundLocalError: local variable 'path' referenced before assignment
Thanks in advance!
It seems something is wrong in your PySide distribution. From the traceback, it shows a problem in the second line of your Feiwings program. In this line there is probably an import statement where you import something from PySide, right?
Apart from the py2exe problem, are you able to execute your code normally without raising the same error?
If so, I would guess that you should include other packages dependencies (eg.: PySide) in your setup, something similar to:
setup(packages=['PySide'],
console=['D:\python\Feiwings.py'])
Hope it helps!
Check the variable 'path' in the program. It seems not a error of Pyside(assuming that you have properly installed Pyside) but the way you have used the variable 'path'. Having a look at the error it seems you have used variable 'path' before assigning it any value.
I would like to have an interface between Python and sqlite. Both are installed on the machine. I had an old version of Python (2.4.3). So, pysqlite was not included by default. First, I tried to solve this problem by installing pysqlite but I did not succeed in this direction. My second attempt to solve the problem was to install a new version of Python. I do not have the root permissions on the machine. So, I installed it locally. The new version of Python is (2.6.2). As far as I know this version should contain pysqlite by default (and now it is called "sqlite3", not "pysqlite2", as before).
However, if I type:
from sqlite3 import *
I get:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/verrtex/opt/lib/python2.6/sqlite3/__init__.py", line 24, in <module>
from dbapi2 import *
File "/home/verrtex/opt/lib/python2.6/sqlite3/dbapi2.py", line 27, in <module>
from _sqlite3 import *
ImportError: No module named _sqlite3
It has to be noted, that the above error message is different from those which I get if I type "from blablabla import *":
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named blablabla
So, python see something related with pysqlite but still has some problems. Can anybody help me, pleas, with that issue?
P.S.
I use CentOS release 5.3 (Final).
On Windows, _sqlite3.pyd resides in C:\Python26\DLLs. On *nix, it should be under a path similar to /usr/lib/python2.6/lib-dynload/_sqlite3.so. Chances are that either you are missing that shared library or your PYTHONPATH is set up incorrectly.
Since you said you did not install as a superuser, it's probably a malformed path; you can manually have Python search a path for _sqlite3.so by doing
import sys
sys.path.append("/path/to/my/libs")
but the preferred approach would probably be to change PYTHONPATH in your .bashrc or other login file.
You have a "slite3.py" (actually its equivalent for a package, sqlite3/__init__.py, so import sqlite3 per se is fine, BUT that module in turns tries to import _sqlite3 and fails, so it's not finding _sqlite3.so. It should be in python2.6/lib-dynload under your local Python root, AND ld should be instructed that it has permission to load dynamic libraries from that directory as well (typically by setting appropriate environment variables e.g. in your .bashrc). Do you have that lib-dynload directory? What's in it? What environment variables do you have which contain the string LD (uppercase), i.e. env|grep LD at your shell prompt?