Thinking about the importance of cross-implementation portability

August 28, 2008

Here is a Python question I have been mulling over since a comment on a previous entry: does code portability across different Python implementations matter very much at the moment?

My suspicion is that the answer is 'not really in practice', because I don't see much motivation for moving code between the different implementations:

  • the three leading implementations ('CPython' (the normal Python), Jython, and IronPython) exist in significantly different environments; you cannot really drop in one as a replacement for another, so you need code that can usefully move between different environments.

    (There is a class of code that can do this: network servers. But a lot of code will not move so easily, with the worst case probably being GUI-based programs.)

  • there is no obvious large Python program that people want to run across different environments; the one possible exception I can think of is Django, but I think that Django is not as influential and widely used as something like Ruby on Rails (which is driving interest in alternative Ruby implementations, Ruby on the JVM, and so on).

  • people might like to move important modules (well, to have them available), but my impression is that the really interesting modules are not pure Python (because of performance issues) and thus already need explicit porting.

(Also, right now if you are going to promise that your Python code is portable to other implementations, you probably need to explicitly test it in them. This may not be easy to do, although I am biased by working on Unix.)

All of this makes me suspect that not very much code moving is really happening and thus portability is really not an issue right now for almost all Python programmers.

Comments on this page:

From at 2008-08-28 11:19:26:

I think you're under estimating the influence of Django - at this point, it is becoming the "defacto" application to "port" over to $implementation, I think to some extent this is due to the GAE deployment of Django. Django is right on track to becoming "our" RoR.

Secondarily, I agree with your assertion that cross interpreter portability is a secondary concern to most python developers versus something like platform portability (Unix vs. Windows). If I am going to use a specific interpreter implementation - I am going to (ab)use the features of that implementation.

For example, Jython - most of my code will run under it just fine, but the real reason I use it is to reach into the Java space and use Java-specific features/libraries. The same applies to IronPython.

Even so - I think there is a common desire to make all of the implementations "close enough" where porting code is a minimal effort, this is a good goal in my book as when the "other" implementations gain even more traction in the user community, having portable code will be key to those consumers - if not the developer of the library/tool.

-Jesse Noller

By cks at 2008-08-29 16:34:18:

I agree that all the alternative implementations are aiming to be CPython compatible, because that gives them access to a large amount of pure Python code and makes them much more attractive. I'm more interested in the question, roughly put, of how hard one should avoid writing things that are almost sure to be implementation specific in one's code, and I think that the answer right now is 'don't worry about it too much'.

Written on 28 August 2008.
« How I think about how important security updates are
We don't really control user desktop machines »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Aug 28 01:06:25 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.