Home Original page

"Portability" (was: How to create a Unix Domain Socket?)

Donn Cave donn at u.washington.edu
Thu Oct 19 12:59:07 EDT 2000 
Quoth Andrew Kuchling <akuchlin at mems-exchange.org>:
| claird at starbase.neosoft.com (Cameron Laird) writes:
|> My personal emotional reaction is that Python
|> shouldn't be like Perl, and shouldn't just expose
|> the OS run-time; it should build in a portability
|> layer for strftime(), socket(), and other notor-
|> ious black sheep.  I suppose I'll just leave it
|
| One risk of this approach is that you wind up following Java's
| least-common-denominator approach.  Not every platform supports
| select()?  Then you can't use select() on any platform at all...

How true, but maybe even worse is the marginal cost of yet another
platform.  Maybe we had set_pants_on_fire() on Windows, UNIX and 
MacOS and so it was no trouble to expose it in our Virtual Machine;
now along comes BeOS with no set_pants_on_fire(), not even a
wheres_my_pants() or set_garment_on_fire().  Java really has been
an awful long time coming to BeOS, despite Sun has supposedly
been on the job for a while.  Python has never been any trouble,
though we don't have Tk.  That's unfortunate, but because we can
treat these as separate issues, I can use Python anyway - and as
I don't personally need Tk anywhere else, that seems fair to me.

But I'm not saying work on portability would be wasted.  Higher
level interfaces could address this problem along with others.
As the target functionality becomes more application oriented, it
might be easier to meet the target on any particular platform with
its native tools, instead of everyone trying to emulate UNIX.
Then the only problem is getting programmers to use it, instead
of the lowest level interfaces they can find.

	Donn Cave, donn at u.washington.edu
More information about the Python-list mailing list