Recommendations for perl-to-python interoperation?

Question

We have a sizable code base in Perl. For the forseeable future, our codebase will remain in Perl. However, we're looking into adding a GUI-based dashboard utility. We are considering writing the dashboard in Python (using tkinter or wx). The problem, however, is that we would like to leverage our existing Perl codebase in the Python GUI.

So... any suggestions on how achieve this? We are considering a few options:

1. Write executables (in Perl) that mimic function calls; invoke those Perl executables in python as system calls.
2. Write Perl executables on-the-fly inside the Python dashboard, and invoke the (temporary) Perl executable.
3. Find some kind of Perl-to-Python converter or binding.

Any other ideas? I'd love to hear if other people have confronted this problem. Unfortunately, it's not an option to convert the codebase itself to Python at this time.

Thanks, --Steve ([email protected])

Answer 1

Try the CPAN distribution Python (pyperl) for interfacing with python code.

Answer 2

You can spawn a child process and use an IPC mechanism like sockets or STDIO, or even embed one interpreter in the other.

But why switch languages when Perl offers several Tk (Tk, Tkx, and Tcl::Tk) bindings and a very capable Wx binding?

I have written and distributed GUI projects with Perl's Tk and Wx libraries.

If you are need the ability to create stand-alone executables, check out PAR::Packer, ActiveState's PerlApp, and Cava Pacakger.

Answer 3

I'd avoid inter-language calls if possible; fragility and massive increases in dependencies await you down this road. However, there is...

Inline::Python

If python must be used, the Inline::* series of modules have been generally well received. This lets you write python inside a perl script. You still have to write perl but it would let you use python libraries inside perl scripts. It will make things more difficult to debug, though.

Answer 4

Well, if you really want to write the GUI in another language (which, seriously, is just a bad idea, since it will cost you more than it could ever benefit you), the thing you should do is the following:

1. Document your Perl app in terms of the services it provides. You should do it with XML Schema Definition - XSD - for the data types and Web Service Description Language - WSDL - for the actual service.
2. Implement the services in Perl, possibly using Catalyst::Controller::SOAP, or just XML::Compile::SOAP.
3. Consume the services from your whatever-language GUI interface.
4. Profit.

But honestly, I really suggest you taking a look at the Perl GTK2 binding, it is awesome, including features such as implementing a Gtk class entirely in Perl and using it as argument to a function written in C - for instance, you can write a model class for a gtk tree entirely in Perl.

Answer 5

I'd think the major criterion for any qualified answer would involve the details of the existing codebase. How is this Perl code called and how does it return it's results?

A collection of command line utilities returning results through reasonably good textual output ("good" as in "amenable to further machine parsing" or "pipeline friendly") ... should be reasonably easy to call from any programming language (and Python's excellent subprocess and multiprocessing modules in particular). A collection of web CGI or other modules layered between Apache and some DBMS system could still be accessed with things like urlopen2 or mechanize -- but it might be better to bypass the Perl code and write Python to query the underlying (presumably canonical) model (data store).

If the majority of the codebase is a set of libraries or modules ... and the functionality that your proposed dashboard requires isn't already exposed via some higher level mechanism (some command line interface, networking protocol, etc) ... then it's basically insane to consider interfacing to it through any language other than Perl. (Unless, by some strange and extremely unlikely twist of fate, your existing codebase and your intended implementation target are both already stable under Parrot).

Let's ask a different, broader, question: What interface to you intend to use between your dashboard and your existing code base?

This question is paramount regardless of your choice of implementation language. If you write the dashboard in Perl it still needs to call into your existing code base in some way. You probably need to fix-up your code base to implement support for whatever your going to use for your dashboard. At the point where your codebase supports the necessary API (has command line or IPC protocol calls into the desired functionality which return results over any reasonable IPC mechanism) ... then your choice of dashboard implementation language will be essentially arbitrary.

Answer 6

I hate to be another one in the chorus, but...

1. Avoid the use of an alternate language
2. Use Wx so it's native look and feel makes the application look "real" to non-technical audiences.
3. Download the Padre source code and see how it does Wx Perl code, then steal rampantly from it's best tricks or maybe just gut it and use the application skeleton (using the Artistic half of the Perl dual license to make it legal).
4. Build your own Strawberry Perl subclass to package the application as an MSI installer and push it out across the corporate Active Directory domain.

Of course, I only say all this because you said "Dashboard" which I read as "Corporate", which then makes me assume a Microsoft AD network...

Answer 7

Interesting project: I would opt for loose-coupling and consider an XML-RPC or JSON based approach.