future of python vs java?

[Alex Martelli]

Mylene Reiners wrote:

> Alex et al,
> 
> Yau definitely have a point here. But aren't you afraid that "Python",
> "Jython" and "Nython" (whatever) will grow in different directions?

No.  I trust Guido and his close collaborators to ensure that these
are just different implementations of the same language.

> I mean, in Java as well as in Python I wrote programs / classes that
> existed already, just because I didn't know they existed (my fault
> undoubtedly, but because of the huge existing native and non-native
> libraries understandable I guess).

Of course.  Java has a dazzling array of libraries and Classic Python
isn't far short.

> Imagine: an existing Nython class written again in "core" Python because
> the existence was not known...

That's quite possible -- if the "Nython class" is a wrapper over
some parts of the .NET libraries, its existence doesn't mean that
some other realization of the same functionality isn't separately
needed in Jython and Classic Python.

The libraries that are available in C or C++ (wrapped fro Classic
Python) and in Java (directly usable in Jython) already differ, of
course -- the same functionality exists in at least two separate
implementations.  If there are standards (e.g. XML, SAX and DOM),
so much the better, but for many other things there aren't.  And
indeed, a good part of the attraction of Jython is _exactly_ that
it lets you use libraries that exist for Java in forms that you
find preferable to the ways similar functionality is implemented
in C or C++.  Nython (if and when it comes) will no doubt offer
similar opportunities.

These issues do not affect the _language_, nor the body of Python
library code that is coded in Python itself and therefore equally
available in CPython and Jython.  If at some time in the future
the need arises for uniform-interface lower-level libraries between
CPython and Jython (and possibly Nython), for fields not covered
by existing standards such as those for XML parsing, then the
groups of people who need such uniformity can make up a SIG and
define a Python-standard -- much like happened for database
interface modules in CPython (each DB engine accepts its own
dialect of SQL, of course, so portability is still an issue, but
the different DBAPI-compliant modules do help a little bit).

More likely, the solution can be a Python-coded wrapper with a
uniform interface to application code but different back-ends
underneath to interface to the different 'native' libraries.
How else could you handle porting Python applications between,
say, SWING and Qt, for example?  Project anygui seems like the
way to go for such needs (smooth both the differences between
different CPython GUI modules, _and_ between those and Java-
oriented GUI frameworks such as SWING or even AWT) -- uniform
Python code with different plug-in backends.


Alex