Calling a Python module from Perl

In the short run the easiest solution is to use Inline::Python. Closely followed by calling a command-line script.

In the long run, using a server to provide RPC functionality or simply calling a command-line script will give you the most future proof solution.

Why?

Becuase that way you aren't tied to Perl or Python as the language used to build the systems that consume the services provided by your library. Either method creates a clear, language independent interface that you can use with whatever development environment you adopt.

Depending on your needs any of the presented options may be the "best choice". Depending on how your needs evolve over time, a different choice may be revealed as "best".

My approach to this would be to ask a couple of questions:

How often do you change development tools. You've switched to Python from Perl. Did you start with Tcl and go to Perl? Are you going to switch to the exciting new language X in 1, 5 or 10 years? If you change tools 'often' (whatever that means) emphasize cross tool compatibility.

How fast is fast enough? Is the start up time for command line solutions ok? Does Inline::Python slow things down too much (you are still initializing a Python interpreter, it's just embedded in your Perl interpreter)?

Based on the answers to these questions, I would do the simplest thing that is likely to work.

My guess is that means in order:

Inline::Python
Command line scripts
Build an RPC server

Inline::Python works quite well, there can be some strangeness when passing certain kinds of variables though.

GWW 2010-08-09 17:15:58

Thank you. I liked all the answers, but this seems very portable.

Arrieta 2010-08-10 15:24:51

Hard to beat simple and well tested, isn't it?

drewk 2010-08-09 16:47:54

Except of course if they need to run in an environment where startup cost of a Python interpreter (times # of expected executions) is way too high. Like an app or a web server, as an example. The way Perl is meant to be used in a situation-appropriate way.

DVK 2010-08-09 17:43:58

@DVK: Python can be used in a variety of ways, also, each appropriate to different situations. Do you know what situation applies to this question?

S.Lott 2010-08-09 19:50:24

@S.Lott - I don't know, but my point was that you don't know as well, yet you recommend one solution WITHOUT explicitly explaining which circumstances it's suited to. And, to be honest, the fact that the OP mentioned a server with RPC calls inclines one to think that there probably was *some* reason why they did not consider command line `system()` calls to be the obviuous solution

DVK 2010-08-09 20:05:18

@DVK: My point was that you seem overly critical about a valid solution without any real basis in fact. You could -- for example -- ask for clarification from the person posting the question rather than make assumptions. I find that many people are ignorant of the standard Unix design pattern of lots of cooperating processes. If this is a pipeline between Perl and Python (where both processes run for the duration of the computation) there's almost no fork overhead. So, I'd prefer you to ease up on the harshness of your criticism. You may be right. But neither of us know, do we?

S.Lott 2010-08-09 20:08:07

@DVK: The OP also posted command line and system calls as an option being considered, so it seems (s)he had not ruled that out (yet) for performance reasons. It is an awful lot easier to debug a system call rather than RPC or `Inline::Python` which is on version 0.21 all things being equal and performance not being a constraint. The OP did not post performance as a concern.

drewk 2010-08-10 01:51:28

@drewk (and S.Lott) - The fact that the OP didn't say anything about performance could mean they don't care; or that they don't KNOW there's a performance penalty (not everyone encountered that particular pitfall); or that they don't quite know the full cost/benefit analysis of possible solutions (that last would be my assessment if I had to pick one of these). My point is that recommending the command line solution WITHOUT providing such cost/benefit analysis (and in abcence of the evidence that the OP was aware of it) is a potential disservice to OP.

DVK 2010-08-10 06:51:05

@S.Lott - sorry, didn't mean to sound "harsh" - I was basically trying to improve/clarify your answer by qualifying it to be more context appropriate. If I meant to be harsh, it'd be a downvote, not a comment :) ... Now... telling that Perl is **meant** to be used on a command line system calls to someone who did both Perl servers and Perl web development for a living - **that's** harsh :)

DVK 2010-08-10 06:57:23

@DVK: "recommending the command line solution WITHOUT providing such cost/benefit analysis" Please. Feel free to post any cost-benefit analysis you see fit. I have no clue what basis you'll use, but that's yours to answer. Just be careful how you criticize other, workable, viable, simple solutions.

S.Lott 2010-08-10 10:02:30

Performance is not as important in my case at this point. The scripts will be called a few times per day and their run time will vastly dwarf the startup time. Useful discussion though.

Arrieta 2010-08-10 15:24:21

ansaurus

tags:

views:

answers:

Calling a Python module from Perl

related questions