scripting language newbie - compatibility

[Paul Duffin]

Alex Martelli wrote:
> 
> "Paul Duffin" <pduffin at hursley.ibm.com> wrote in message
> news:398DE3F2.CDDD1103 at hursley.ibm.com...
>     [snip]
> > Where was Python originally developed ? UNIX ? Windows ? Mac ?
> 
> Apparently, a Mac was what Guido had on hand, Unix the main
> target, and perfect cross-platform operation the goal from day 1.
> 
> My current Python usage is overwhelmingly on Windows platforms,
> and I find it very interesting that Python performs so perfectly on
> what IS, after all, neither of the 'main' platforms above.
> 

I had a feeling that the Windows version of Python while being part of the
core was supported seperately in some way.

> > I personally think that Tcl is the most cross platform language of the
> > three that the original poster mentioned. I have not used the others but
> > have spent some time looking at how each language implements the features
> > that I want and find that for my use Tcl is a better cross platform
> > solution.
> 
> I *have* used them all (Java, Tcl, Python, Perl, and more besides), and
> on the basis of this extensive experience I find that Python is just "the
> cat's pajamas" for cross-platform work (as well as most other points
> of view:-).  Not that problems with the others were anywhere deep in
> *the languages* from a specifically *cross-platform* viewpoint, mind
> you -- issues such as the lack of fork on non-Unix platforms can hardly
> be patched at the language-level (I heard that ActiveState was working
> on a kludge for that over a year ago, but dunno what if anything ever
> became of that effort).  Java may suffer from the risk of relying on a JVM
> that's not under your control on the target machine -- with the others you
> KNOW you need to distribute the interpreter as well (which you could
> do with Java too, but it may be more of a problem).  Perl and Tcl suffer
> from not being able to distribute cross-platfom _compiled_ forms, but

Actually you can generate byte compiled versions of Tcl which you can
distribute but you need to use a commercial package called TclPro to
do that. It is certainly not as easy as Python but pre byte compiling Tcl
code is not as useful as pre compiled Python code because of Tcl's dynamic
nature.

> I find that minor; and lack of deep/well-integrated OO, but that's not a
> cross-platform issue, really.
> 
> But really, I'm most curious to hear about what makes Tcl 'better' for
> cross-platform work in your view.
> 

You asked for it. Please note that I am not flaming Python in anyway, just
highlighting some of the ways in which I think it could be improved.

I like the abstractions that Tcl places on top of things like I/O.

I think that event driven programming is much cleaner than threads for many
problems and Tcl excels at that even on Windows which doesn't really like
event driven programming. WaitForMultipleObjects is a poor substitute for 
select, especially when it comes to sockets.

Tcl's [socket] command is a very powerful abstraction which makes it 
trivially easy to write simple client server code.

Python and Perl on the other hand both provide access to the low level 
socket/bind/accept/connect calls which are harder to use. This low level
access would also make it harder to implement on a system which provides
support for sockets in a different way. This may not be particularly likely
for sockets but applies to other things as well.

One of the other things that I think that Tcl does better than Python in
terms of cross platform support has to do with linking. 

On Unix Python is built as a static application and uses backlinking in 
order to expose its C API to extensions. On platforms such as AIX which
did not support backlinking it would emulate it using some lower level
functions. This takes an incredible amount of effort and code and works
remarkably well. I certainly learnt a lot about AIX by looking at the
code which does that.

Using backlinking to expose the C API to extensions is very flexible
(although not without its problems) as it allows you the choice of how
you package up Python while still letting you extend it by loading new
extensions. e.g. you could create one monolithic executable which contains
everything that you want and is easy to distribute, or you could create
shared library versions of Python and the modules.

The trouble is that Windows has absolutely no support for backlinking 
whatsoever so in order to load extensions Python has to be built as a DLL
and every extension has a dependency on that particular version of Python
so they have to be recompiled, or the Python dll has to have a generic
name which does not contain the version number.

Tcl on the other hand does not rely on the operating systems linking
mechanism to expose its API to its extensions, rather it explicitly
gives the extension a pointer to tables of function pointers to all 
the exported functions.

Macros are provided which invisibly map function calls to calls through
the table. This means that when the extension is built it does not
have any unresolved references to the Tcl C API so the operating systems
loader does not get involved at all.

This means that Tcl behaves the same way on all platforms irrespective
of the behaviour or limitations of the platforms loader.

This "Stubs" mechanism is very simple but solves a lot of problems.
e.g. say that you want to rationalise the Python C API by removing
old functions but still provide a backwardly compatible API to
existing extensions. This can easily be done by having two sets of
tables and giving new extensions a pointer to the new table and old 
extensions a pointer to the old table.

If anyone is interested in adding Stubs to Python then feel free to
contact me as I am more than willing to help.