Thinking about the importance of cross-implementation portability
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:
|
|