portability

[Alex Martelli]

"franck delarue" <franck.delarue at rd.francetelecom.com> wrote in message
news:9k5u2c$p542 at news.rd.francetelecom.fr...
> hello everyone,
> i'm working on python on linux red hat and i'm wandering if all the code
> that i've written would be portable to unix or windows (except the system
> calls of course). I know that python works a little like java ( on a
virtual
> machine), but is Python as portable as java ?

Python isn't quite as portable as Java, because Java by defaults
shields you from all platform-dependencies, while Python's
general attitude is to give you access to platform-dependent
features -- which may not be there on another platform.  So,
writing portable, cross-platform code in Python, while quite
feasible and not all that hard, DOES require more conscious
attention and care than it does in Java (you can of course
use Jython, Python for the Java Virtual Machine, in order to
write Python code but get Java portability).

While most non-portability issues with Python's standard
library are indeed with "system calls" (e.g., you won't get
os.fork on Windows platforms, because the operating system
doesn't support that -- it's for Unix and Unix-like platforms
only), there are (unfortunately, I would say) some (IMHO) less
forgivable portability holes.  For example, module time
exposes a parsing function strptime on SOME platforms only --
those whose underlying C library supplies strptime (and if
the underlying platform's strptime is flaky or non-standard,
so is Python's time.strptime).  There are pure Python versions
of strptime around, but for some reason the Python core team
never decided to integrate those in the standard Python library
so that time.strptime would be usable on all platforms -- in
the pure-Python version if need be, in a native-code one (for
speed) if available & reliable.

This is, unfortunately I feel, rather a good symbol of Python's
overall approach to portability: quite achievable *if you work
at it* (it's less work to make your Python code portable, than
it would be for, say, C, or C++), but definitely a secondary
issue (it takes a lot MORE work to make your Python code
portable than it would take for, say, Java, or Tcl).


Alex