Re: Python portability planning ( and prototypes )

Guido van Rossum (Guido.van.Rossum@cwi.nl)
Wed, 05 Feb 1992 00:14:18 +0100

Steve makes some good points again! I'll think about it more in
three weeks, when I foresee I'll have some spare time again; for now
I'll just respond to his "management summary" at the end.

>Using the success/failure of modules posix|mac|dos|{whatever} to
>determine what machine & system the program is executing on
>( which is needed to do un-portable things portably ) is not
>a good idea because it will conflict with 'aliasing' the modules
>to provide portability. ( for example: making a posix.py module
>for mac that attempts to provide some posix compatible emulation. )

This depends on what you want to do. If the attempt at posix
compatible emulation is good enough it doesn't matter whether
os.system == 'posix' or not, as long as I can say posix.stat(filename).

I don't see much use for knowing the CPU type, byte order, word size
and floating point format unless pack/unpack get implemented. Come
on, most C code doesn't know or care about these (surely 99% of my own
code doesn't make any assumptions beyond what ANSI C guarantees), so
why should Python programs care?

There's one problem, however, which I can't completely "abstract
away": filename syntax. I've attempted to isolate all knowledge about
pathnames in module path (or macpath on the Mac) but this is
incomplete, e.g., the released version has no predicate to test for
absobute pathnames, path.split() leaves a trailing '/' on the
directory name, there should be functions to normalize pathnames in
several ways (e.g., unify case, remove ignored characters, truncate
long names, remove "../", and expand ~ and ~user). I am slowly adding
such functionality as the need arises, but I can't predict what
problem shows up on the next system I port it to (VMS comes to mind as
a good test case :-).

I admit that I've never really sat down and thought about an interface
to do every conceivable operation on pathnames. Maybe there aren't
that many that are actually used, and we can come up with an interface
that will survive into the next century -- I don't know.

I do feel that with something like module path, Python has an
advantage over Tcl: there the Mac port was obviously an afterthought,
and apparently UNIX pathnames are used throughout Tcl's implementation
or in its standard library interfaces in a way that they aren't in
Python -- or why else would they even consider doing automatic
translation to Mac pathnames? (OK, I didn't follow that discussion.)

--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"Time is an illusion. System time doubly so."