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

[Cameron Laird]

In article <39EEE7D8.1059A34F at holdenweb.com>,
Steve Holden  <sholden at BellAtlantic.net> wrote:
>Cameron Laird wrote:
>> 
>> I'm going to grumble briefly--or perhaps ask for help.
>> I'm getting tired of calling Python "wonderfully por-
>> table" or whatever it is I say when I'm acting as an
>> advocate.  I know what I mean by it, but for most
>> people, most of the time, Python's not quite up to the
>> portability of C, and almost every other language is
>> equally tender on the point.
>
>Don't know that I'd agree with that.  In my (limited)
>experience with C, the thing that tripped me up most moving
>between platforms was differences in library semantics: i.e.
>the language is the same on all platforms, but the underlying
>support code differs, sometimes in subtle, non-obvious ways.
Sooooo true.  I suspect there's some artifact
of my personal history operating here, but it
surprises me nowadays how often I hear porta-
bility concerns about *languages*, when, as
you write, it's almost always the run-time
libraries where the problems lie.  I think it's
worth a follow-up to emphasize tha.
>
>Given that the Python library offers MUCH higher-level
>functionality, I find there's a remarkable degree of poertability.
I do *not* find it remarkable.  Ha!--it's the
higher-level stuff that's easier to get right,
or at least invariant.
>
>>				  So:  what's a good word
>> to express, "available on lots of platforms, more or
>> less, and, whatever the semantics are on any particular
>> one, there's an entertaining story to explain why it's
>> so"?
>
>Might I suggest "The usual portability concerns apply to Python
>just as much as any other language"?  The fact is that it's always
>tempting to implementors to expose underlying OS support in
>scripting systems such as Python, and when there's a variety of
>platforms then there'll be a variety of non-portable constructs
>in library usage.
Part of my growsing is uncertainty about
whether that's a temptation or a responsibility.
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
at the level that I'm curious to hear what Guido
and the other silverbacks think about
  exposing the OS
vs.
  construction of a library coders use portably.
			.
			.
			.

-- 

Cameron Laird <claird at NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html