I have a C extension module for Python and I want to make it available to Rubyists.
The source has a number of C modules, with only one being Python-dependent. The rest depend only on each other and the standard library. I can build it with python setup.py build in the usual way.
I've been experimenting with adding Ruby support using newgem and I can build a version of the extension with rake gem. However, the combined source has an ugly directory layout (mixing Gem-style and Setuptools-style structures) and the build process is a kludge.
I can't just keep all the sources in the same directory because mkmf automatically picks up the Python-dependent module and tries to build that, and users shouldn't have to install Python to compile a module that won't be used. My current hack is for extconf.rb to copy the Python-independent source-files into the same directory as the Ruby-dependent extension module.
Is there a saner way to make the code available to both languages? Should I just duplicate the Python-independent code in a separate Gem? Should I release the independent code as a separate lib built with autotools? Is there a version of mkmf that can skip the unwanted module?
One way to solve it is to create three different projects:
The library itself, independent on python & ruby
Python bindings
Ruby bindings
That's probably the cleanest solution, albeit it requires a bit more work when doing releases, but it has the advantage that you can release a new version of the Ruby bindings without having to ship a new library/python bindings version.
Complementing on what Johan said, I've used a couple c/c++ support libraries in Python thanks to swig. You write your code in c/c++ then make an intermediary template for each language that you want to support. Its rather painless for Python, but some considerations must be made for Ruby... namely I don't think pthread support is to happy with ruby or vice versa.
http://www.swig.org/
It's got a somewhat steep learning curve so it might be best to find an example project out there that demonstrates how to use the wrapper for your target languages.
This is definitely a useful tool as it makes your code a lot cleaner while still providing robust bindings to multiple languages (PHP, Python, Ruby, and I believe c#)
Related
I'm trying to build a minimal Python static library for distribution in an app. This is the C API I need to link to, I believe it may be called CPython as well. I don't need to package actual Python scripts, just link to the library itself.
I've built 3.7.4 by doing:
./configure --disable-shared
make
This does build a library libpython3.7m.a which is 12.4MB. Is it possible to reduce this size at all? I need an absolute barebones distribution without any of the normal packages. Literally this is just for a scripting bridge and doesn't need any of the usual Python functionality.
If you're trying to link to Python's Extension API, you won't find much luck in shaving off size from the libpython shared object. This is because the Extension API uses the same types and headers as the core interpreter (which is why it's called extensions instead of something else like plugins), granting the extensions runtime access to the inner mechanics of the interpreter that normal python scripts wouldn't allow. Basically, the libpython object is just the interpreter compiled without an entry point and an additional frontend so that the expression of simple python operations (e.g. parsing function arguments) stays a clean development experience.
If you're using Python 3.2+, there is offered a "Limited API" for the version of python you are trying to target, but the point of this is to guarantee a stable ABI as the extensions API evolves, not to reduce the size of the compilation unit.
I would also like to mention that the term CPython is just a way to disambiguate the vanilla Python distribution from similar but incompatible interpreters like Pypy.
I've built a fairly complicated application with PyQt4 and Python, but it is a pain to send to people (and once I do, they have no idea how to run it). Then there are dependencies to wrestle. Ugh.
Anyways, I just learned about Jython, and since virtually everybody has Java installed, it seems like a perfect solution to my problem of distribution of Python scripts. Has anybody actually developed a functional piece of software with Jython, and if it even exists, one with Jambi bindings?
I'm just asking so that I don't go digging for something which doesn't work.
Thanks!
If you did move this application to Jython, you would have to convert the GUI from QT to Jambi.
Jython is the Python language implemented in Java to run on the Java virtual machine. Because it runs on the JVM, Jython apps can use any Java libraries, such as SWING or Jambi.
It is possible that the differences between PyQT and Jambi are very small, but fundamentally, you would not be using QT directly. Instead you would be using Jambi. And if you use any non-standard Python modules you will still have to resolve packaging issues.
If your application uses other Python modules which are implemented in C, then you would also need to replace those with Java libraries. Jython is great at running a lot of pure Python code unchanged, but Jython runs in a Java environment and there are differences in the way some fundamental objects, such as strings, are implemented. Jython uses Java internals, Java's garbage collector, and so on.
There is more info available via this SO question: Migrating from CPython to Jython
I used cpython api to load py from C/C++.
But, if i want not setup cpython in client, can I take package dll of cpython in my program?
How to do that?
Installer-builders like PyInstaller (cross-platform) and py2exe (Windows only) basically do that job for you in a general way, except that the executable at the heart of the produced package is their own instead of yours.
But basically, you can imitate their behavior in terms of setting up a .zip file with all the Python library modules you need (or just zip up everything in the standard python library if you want to allow python code running form your app to import anything from there), and follow the simple advice in the Embedding Python in Another Application section of the Python docs.
Note that embedding Python equals extending Python plus a little bit of code to initialize and finalize the interpreter itself and a little bit of packaging as I just mentioned; if you've never writted Python extensions I would suggest practicing that first since it's the most substantial part of the task (not all that hard with helpers such as boost python, but more work if you choose to do it as the "bare C" level instead).
You don't need to setup Python to embed it in applications. The core of the Python interpreter is available as a shared library which you can dynamically load in your application and distribute with it.
Read on embedding Python in the official docs. Also, this article seems nice and comprehensive for Linux. For Windows, read the notes here.
Here's another SO question that discusses this issue.
The Python license is probably hard to understand for a non-lawyer, non-native English speaker. So yes, you can redistribute the unmodified DLL as it contains the copyright notice within it.
It would be polite to give credit like "This program contains the Python Language Interpreter version X.XX http://python.org for more information" or similar somewhere in the program or documentation.
I recently started learning Python. Not yet ventured into coding.
During one of my learning sessions, i came accross the term Jython.
I googled it & got some information.
I would like to know if anyone has implemented any real-world program using Jython.
Most of the time, Jython isn't used directly to write full read-world programs, but a lot of programs actually embed Jython to use it as a scripting language.
The official Jython website gives a list of projects, some written in Jython, others using Jython for scripting:
http://wiki.python.org/jython/JythonUsers
I am writing a full application in Jython at the moment, and would highly recommend it. Having all of the Java libraries at your disposal is very handy, and the Python syntax and language features actually make using some of them easier than it is in Java (I'm mostly talking about Swing here).
Check out the chapter on GUI Applications from the Jython book. It does a lot of comparisons like 'Look at all this Java code, and now look at it reduced to Python code of half the length!'.
The only caveats I've found are:
Jython development tends to run slightly behind Python, which can be annoying if you find a cool way of doing something in Python, only to discover it's not supported in the current Jython version.
Occasionally you might have hiccups with the interface between Python and Java (I have a couple of unsolved problems here and here, although there are always workarounds for this kind of thing).
Distribution is not as simple as it could be, although once you figure out how to do it, it's fairly painless. I recommend following the method here. It essentially consists of:
Exploding jython.jar and adding your own modules into it.
Writing and compiling a small Java class that creates a Python interpreter and loads up your Python modules.
Creating an executable .jar file consisting of the jython.jar modules, your own Python modules, and the Java class.
Jython really shines for dependency injection.
You know those pesky variables you have to give your program, like
file system paths
server names
ports
Jython provides a really nice way of injecting those variables by putting them in a script. It works equally well for injecting java dependencies, as well.
WebSphere and WebLogic use it as their default scripting engine for administrative purposes.
A lot of other Oracle products ship it as part of their "oracle_commons" module (Oracle Universal Installer, Oracle HTTP Server etc). It's mostly version 2.2 being deployed though, which is a bit old and clunky.
There is a list of application that uses jython at http://wiki.python.org/jython/JythonUsers
I'm an extension noob. What I want to do is create an extension that doesn't require other libraries to be installed. Is this impossible because the extension has to link against a specific version of libpython at runtime?
You can't make a statically linked extension module because Python needs to load it dynamically at runtime and because (as you reasoned) the module needs to dynamically link against libpython.
You could compile your own custom version of Python with your extension statically linked into the interpreter. That's usually more trouble than it's worth.
Why do you want to make a statically linked extension? If we have more information about your goals, we might be able to help you achieve them in a different way.
Welcome to StackOverflow. :-)
I think you're mixing things. You don't want the extension to be statically linked in the interpreter (which is possible but cumbersome since it involves rebuilding a custom interpreter), you want your extension not to be linked against pythonxx.dll, or to be linked statically to it. This is not possible; your extension and the python interpreter would have each their own copies of global variables for instance, which is Bad.
There is another approach, which is to determine what Python versions are available at runtime and using dynamically the Python/C API by loading the Python DLL through LoadLibrary (Windows) or dlopen (Linux/etc), then deciding at runtime on the methods signatures depending on the version, etc. Very cumbersome. For an example of this kind of manipulation in Delphi, see PythonForDelphi:
http://www.atug.com/andypatterns/pythonDelphiTalk.htm
I'm not aware of any other project who would do that.