I want to call legacy c third party functions from python.
I created a C api to make the function calls simpler.
In my python file
I tried to import the *.so for the api which links with the legacy code library.
But I kept seeing a libxxx ( the legacy c library) not found error.
I tried to import both ans still saw the same error.
I then tried using ctypes, but get the error ctypes not found.
Any suggestions ?
# python
Python 2.4.2 (#1, Apr 20 2012, 19:31:49)
[GCC 4.1.2 20070115 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ImportError: No module named ctypes
>>> quit
ctypes only made it into the standard library in version 2.5, so 2.4 does not have it. I've also heard that some people exclude it when they build Python for a distribution or for embedding in a specific application, as you can easily crash your process using it, or even corrupt the host application's heap. But I have never encountered this myself, and I doubt a full installation does this.
As for not finding your C library, we'll need more details on that.
Related
I have created a virtual ubuntu machine and installed ALLENNLP,
In that and tried example from ALLENNLP demo website
I have executed below code
from allennlp.predictors.predictor import Predictor
import allennlp_models.tagging
predictor = Predictor.from_path("myLocalPath/stanford-sentiment-treebank-roberta.2021-03-11.tar.gz")
predictor.predict("a very well-made, funny and entertaining picture.")
which gave me below error.
>>> predictor.predict("a very well-made, funny and entertaining picture.")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/.local/lib/python3.8/site-packages/allennlp/predictors/text_classifier.py", line 24, in predict
return self.predict_json({"sentence": sentence})
File "/home/.local/lib/python3.8/site-packages/allennlp/predictors/predictor.py", line 54, in predict_json
instance = self._json_to_instance(inputs)
File "/home/.local/lib/python3.8/site-packages/allennlp/predictors/text_classifier.py", line 40, in _json_to_instance
return self._dataset_reader.text_to_instance(sentence)
File "/home/.local/lib/python3.8/site-packages/allennlp_models/classification/dataset_readers/stanford_sentiment_tree_bank.py", line 114, in text_to_instance
assert isinstance(
AssertionError
But when I executed below code
from allennlp.predictors.predictor import Predictor
import allennlp_models.tagging
predictor = Predictor.from_path("myLocalPath/sst-roberta-large-2020.06.08.tar.gz")
predictor.predict("a very well-made, funny and entertaining picture.")
It worked.
Only difference between above two code is version of roberta-large train data
I have installed latest version of ALLENNLP in my virtual machine
I don't have NVIDIA graphic card in my virtual machine could this be a reason?
But then how come other version is working?
Please help
Allen NLP version was the issue it was ALLENNLP 2.1.0, It worked with ALLENNLP version 2.4.0.
Use command "pip install allennlp"
and then "pip install allennlp-models"
instead of "pip install allennlp==[some version] allennlp-models==[some version]"
or make sure you have version greater than or equal to 2.4.0.
I have some Cython code that currently looks
exc = sys.exc_info()
raise exc[0], exc[1], exc[2]
This doesn't work on Python3, since the "raise from tuple" form is no longer allowed. Were this normal Python code, I would just use six.reraise, but that's not available to me here. What's the Cython friendly way to do the same, which works on both Python2 and Python3?
One great Cython feature is that the generated C code can be compiled for either Python 2 or Python 3. So your example above will work with either version of Python, unmodified.
You can tell Cython to compile code assuming Python 2 syntax and semantics (the -2 argument, which is on by default) or assuming Python 3 (the -3 argument). In either case, the resulting extension module source code can be compiled and used for Python 2 or Python 3, as long as the dynamic components (imports, etc.) are compatible.
For example:
def raises_exception():
raise KeyError("what you doin'?")
def foobar():
try:
raises_exception()
except Exception:
import sys
exc = sys.exc_info()
raise exc[0], exc[1], exc[2]
Here's a setup.py that will work on either Py2 or Py3:
from distutils.core import setup
from Cython.Build import cythonize
setup(ext_modules=cythonize("reraise.pyx"))
I can run python setup.py build_ext -i on either version of Python (provided I have cython installed for each), and the resulting extension module will work.
$ python setup.py build_ext -i # Py3 python
$ ipython3
Python 3.3.2 (v3.3.2:d047928ae3f6, Oct 4 2013, 15:49:17)
Type "copyright", "credits" or "license" for more information.
IPython 1.2.1 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
In [1]: import reraise
In [2]: reraise.foobar()
---------------------------------------------------------------------------
KeyError Traceback (most recent call last)
<ipython-input-2-9e20eacfd84e> in <module>()
----> 1 reraise.foobar()
/.../reraise.so in reraise.foobar (reraise.c:916)()
/.../reraise.so in reraise.foobar (reraise.c:847)()
/.../reraise.so in reraise.raises_exception (reraise.c:762)()
KeyError: "what you doin'?"
In [3]:
I've been trying to get Kivy to work on my Mac (Lion), but I've been encountering issues. I followed the instructions on the Kivy site, and since Kivy 1.8 supports Python 3, I wanted to run it with 3.3, and I finally got that to work, by editing the kivy file to point to 3.3 instead of 2.7. I tried drop a .py program on the Kivy icon, the app opened but nothing happened. So I tried to run it from the command line. It opened 3.3, as expected, but I got the following error.
Python 3.3.4 (default, Mar 6 2014, 20:14:14)
[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygame
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Applications/Kivy.app/Contents/Resources/lib/sitepackages/pygame/__init__.py", line 127, in <module>
from pygame.base import *
ImportError: dlopen(/Applications/Kivy.app/Contents/Resources/lib/sitepackages/pygame/base.so, 2): Symbol not found: _PyCObject_Type
Referenced from: /Applications/Kivy.app/Contents/Resources/lib/sitepackages/pygame/base.so
Expected in: flat namespace
in /Applications/Kivy.app/Contents/Resources/lib/sitepackages/pygame/base.so
I have no idea why I would get this error, since I previously installed pygame for 3.3, and import pygame or from pygame.base import * work error free. Would this issue with pygame explain why .py files fail to execute when I drop them onto the Kivy icon?
Kivy.app and all the dependencies included in it is compiled with and for Python 2.7. You cannot use it for 3.3.
If you want to try Kivy with 3.3, you also need to compile Kivy yourself :)
I'm using IronPython and the clr module to retrieve SQL Server information via SMO. I'd like to retrieve/store this data in a SQL Server database using SQL Alchemy, but am having some trouble loading the pyodbc module.
Here's the setup:
IronPython 2.6.1 (installed at D:\Program Files\IronPython)
CPython 2.6.5 (installed at D:\Python26)
SQL Alchemy 0.6.1 (installed at D:\Python26\Lib\site-packages\sqlalchemy)
pyodbc 2.1.7 (installed at D:\Python26\Lib\site-packages)
I have these entries in the IronPython site.py to import CPython standard and third-party libraries:
# Add CPython standard libs and DLLs
import sys
sys.path.append(r"D:\Python26\Lib")
sys.path.append(r"D:\Python26\DLLs")
sys.path.append(r"D:\Python26\lib-tk")
sys.path.append(r"D:\Python26")
# Add CPython third-party libs
sys.path.append(r"D:\Python26\Lib\site-packages")
# sqlite3
sys.path.append(r"D:\Python26\Lib\sqlite3")
# Add SQL Server SMO
sys.path.append(r"D:\Program Files\Microsoft SQL Server\100\SDK\Assemblies")
import clr
clr.AddReferenceToFile('Microsoft.SqlServer.Smo.dll')
clr.AddReferenceToFile('Microsoft.SqlServer.SqlEnum.dll')
clr.AddReferenceToFile('Microsoft.SqlServer.ConnectionInfo.dll')
SQL Alchemy imports OK in IronPython, put I receive this error message when trying to connect to SQL Server:
IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.3607
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlalchemy
>>> e = sqlalchemy.MetaData("mssql://")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "D:\Python26\Lib\site-packages\sqlalchemy\schema.py", line 1780, in __init__
File "D:\Python26\Lib\site-packages\sqlalchemy\schema.py", line 1828, in _bind_to
File "D:\Python26\Lib\site-packages\sqlalchemy\engine\__init__.py", line 241, in create_engine
File "D:\Python26\Lib\site-packages\sqlalchemy\engine\strategies.py", line 60, in create
File "D:\Python26\Lib\site-packages\sqlalchemy\connectors\pyodbc.py", line 29, in dbapi
ImportError: No module named pyodbc
This code works just fine in CPython, but it looks like the pyodbc module isn't accessible from IronPython.
Any suggestions? I realize that this may not be the best way to approach the problem, so I'm open to tackling this a different way. Just wanted to get some experience with using SQL Alchemy and pyodbc.
its very likely that pyodbc is not compatible with IronPython, as it was designed for usage with cPython.
IronPython certainly has some kind of ODBC (actually, ADO.net seems like where its at) compatibility built into it, but a DBAPI would be the most direct way to get SQLAlchemy working with it.
So here's some MS-specific non-DBAPI example: http://www.ironpython.info/index.php/Accessing_SQL_Server
someone talking about DBAPI in 2006: http://hex-dump.blogspot.com/2006/10/ironpython-and-adonet-part-2.html
something a little more recent: http://bitbucket.org/jdhardy/adonet-dbapi/
It says something that MS pours however much money into IronPython but zero into a compliant DBAPI driver.
You could try using SQLAlchemy's adodbapi support instead; the latest version of adodbapi (2.3.0) supports IronPython.
You should only have to make sure the adodbapi package is on sys.path, and then use 'mssql+adodbapi://' instead of 'mssql://' in your connection string.
adodbapi seems the way to go, but here's a snippet from adodbapi.py that ships with SQL Alchemy under the dialects folder
"""
The adodbapi dialect is not implemented for 0.6 at this time.
"""
SQLAlchemy can not directly run under IronPython, because pyodbc currently is not compatible with IronPython.
However, you can use pypyodbc under IronPython as a dbi-2.0 complaint library, which is similar to pyodbc,and enables running sqlalchemy under Ironpython, this How-to describes the 4 steps to enable it.
Disclaimer: I'm the maintianer of pypyodbc.
I know it's something silly, but for some reason Jython refuses to find javax.swing. I'm using Java 1.6.0_11. This is my start-up script:
#echo off
"%JAVA_HOME%\bin\java" -Xmx1024M -classpath ".;c:\Projects\Jython2.5.1\jython.jar" org.python.util.jython
My output looks like:
Jython 2.5.1 (Release_2_5_1:6813, Sep 26 2009, 13:47:54)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_10
Type "help", "copyright", "credits" or "license" for more information.
>>> import javax.swing
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named swing
>>> import javax
>>> dir(javax)
['__name__']
>>>
Most likely Jython is not scanning your packages. On startup, Jython tries to go through the jars and class files on its path and scan for Java packages. This is necessary because there is no way to look for Java packages by reflection. Package scanning can be deliberately turned off, or you could lack write privileges where it wants to write the cached information out see http://wiki.python.org/jython/PackageScanning for more. The best way to import Java classes is to do so explicitly class by class, like so:
from javax.swing import JFrame
This method should always work, even if package scanning is off or otherwise unable to work, and is the recommended approach (though it can be a bit tedious). If you do want to import packages (or if you want to do "from javax.swing import *" which also depends on package scanning - but is discouraged) you will need to figure out why your package scanning isn't working.
I had similar issues, and it turns out that since the standalone Jython dist does not support caching, it also does not support the "import *" approach. This is not clearly documented anywhere in the official Jython docs, but I concluded this based on a number of different bug reports:
https://groups.google.com/forum/?hl=en&fromgroups=#!topic/robotframework-users/6ipB0DYJkvU
http://bugs.jython.org/issue1778514
http://bugs.jython.org/issue1422
http://bugs.jython.org/issue1692579
Notable from that last link:
So as Oti noted, in standalone you must do full imports to succeed.
To fix your issue, use the non-standalone standard jython.jar generated by installing jython using the 'Standard' option.
If you wanted to package and distribute jython.jar with your application, in case a user does not have Jython installed, then you will also need to copy/pase the complete "Lib" folder from the jython installation directory into whichever location you end up placing jython.jar. This enables access to the python stdlib which is not included in the standard jar file.
UPDATE:
After playing around more, I think I have a fix to enable "import *" type imports even when using the standalone jar. All that needs to be done is to enable caching!
You can do this by either adding the following options to the jvm when running jython:
-Dpython.cachedir.skip=false -Dpython.cachedir=DESIRED CACHE PATH
(Note that the second argument is optional, and if left blank, a default value will be used)
If you are having an issue running the InteractiveConsole embedded in an app (which is what my problem was) you can add these properties before initializing the console:
Properties props = new Properties();
props.put("python.cachedir.skip", "false");
props.put("python.cachedir", "DESIRED CACHE PATH"); // again, this option is optional
InteractiveConsole.initialize(System.getProperties(), props, new String[0]);
I'm using Java 1.6.0_11
No, you're using
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_10
What happens if you delete the cachedir from the Jython distribution directory, and try again?
Also, why are you explicitly setting the classpath that way? Why not simply
java -jar jython.jar
?