Message1410

>javapath acts as any other platform specific os.path implementation

Yes, I thought about that. The problem is the JVM is both "a tool" _and_ "a platform". Depending on your particular definition and viewpoint, javapath is / not the right answer.

I can certainly see the rationale to say "Jython runs on the Java Platform" and thus os.path should always be javapath.

However that creates several problems, as it's inconsistent with the view "Jython runs on [Windows/Unix/...]".

Fundamentally, the JVM itself is skitsofrenic(sp?).

In this case, I think it's more correct to make os.path the same as CPython does - the 'native' flavor (ntpath, posixpath, etc) with an option to use a 'java-centric' flavor as an alternative.

This seems historically consistent (if you can use such a phrase regarding this), witness file system notation (values for that String parameter to the File constructor). If the JVM were truly its own platform, you'd use one notation regardless of the underlying system (see Cygwin for an example of how to ignore the native notation in favor of your own dogmatically consistent world view; right or wrong is irrelevant, at least it picks a single world view and sticks to it).

More significantly (IMO), using the 'native' *path.py is in line with recent trends in Sun's JVM (1.4 and, esp, 1.5+). Witness the XP and GTK visual themes for Swing, the getFreeDiskSpace API (finally) in 1.6 (which one could argue merely continues the java.io not-hiding-the-underlying-platform pattern since Java 1.0) and so forth.

And philosophy aside, here's a more concrete example: os.path.splitunc()
Should that exist in Jython's os.path module?

CPython says yes, it exists, on Windows (and nowhere else).
What would a Jython user expect?

Is a Jython developer building a Windows application using Java?
Or is a Jython developer building a Java application that happens to run on Windows?

The true underlying crux of the matter.

IMO there are far more people interested in writing Windows apps that happens to run in the JVM than vice versa.

And CPython fundamentally takes this approach.
One of the things beloved of Python: you *can* write portable code, but you don't *have* to.

This is one of Python's huge *strengths*, and Java's weakness.
Want to access the registry on Windows? Curses on Unix? ... Go ahead. Python not only allows it, Python will help you.
You're not required to write platform-specific code, but you're also not only not-precluded, you're outright aided and abetted. If you so choose.

If you so choose.

That's one hugely compelling benefit I see in Python vs. Java.

Python gives you the power to choose, what best fits YOUR needs.
Java dictates and limits your choices. You're not allowed to write non-portable code, because that would be...bad. So not only does Java avoid helping you, it actively hinders you.

[Witness the GetFreeDiskSpace scenario...]

It's only in recent years that Java's started to loosen up and (start to) embrace The Python Way <g>



This is a long winded way of saying yes, it's reasonable for some people to want to code to the os.path=javapath model, but it's more useful and expected for os.path=nativepath as a default while not precluding those who want the javapath model (hence the reason I added the System.getProperty() check).

And it's not only more useful and expected, but os.path=nativepath is also the right answer because it's consistent with The Python Way -- portability is nice, but not at the cost of freedom and functionality. If you wanted your functionality constrained and dictated, you can always use Java :->