Python 3.0 unfit for serious work?

[Jay Tee]

On Feb 21, 8:06 pm, olso... at verizon.net wrote:

> I don't know the specifics of your app, but why does everyone insist
> that they need to use the 'system' python?

Hey Grant, don't worry it's not a rant.  A completely valid question.
Again it's a problem of dependency management ... one of the things
we've had to deal with is one of the applications : they have a
framework largely built in python, and I think they were indeed at one
point shipping their own python because they used features not present
in the "system" python.

However, they did use the middleware installed on the system, and this
middleware is also partially written in python ... except it was
expecting the system python.  So you get into very tricky things
having to sanity check the PYTHONPATH, that the "user" python path is
not getting exported into middleware land, nor is the application's
desired PYTHONPATH being destroyed by middleware.  We had just such an
issue here last week, we had solved the problem for bourne shell
users, but csh for some reason had a different behavior, and the user
app could not longer find its python modules.

About the only code for which we don't seem to have these issues is
compiled C.  C++ is nasty because the compilers are still catching up
to the standard; the last I heard, a big segment of C++ code was stuck
because it was full of apparently illegal constructs that the previous
compiler (the g++ shipped stock with RHEL3) accepted, but the RHEL-4
native version refused to compile.

A colleague of mine pointed out today that this is an old problem, and
used to be handled by automake at compile time, with code full of
ifdefs ... now we've moved the problem to run time.  Which I think is
harder, because sometimes we don't find the problem until our binary
is halfway across the world ...

JT