Message1412

>I agree dividing javapath into separate modules would be The Right Thing
I didn't say that, or at least didn't mean to, though it did cross my mind.

Problem: Today, import ntpath does not work, so even if you wanted access to the various non-javapath goodies, you can't do it. And to be honest, I'm not sure why -- import posixpath and so forth work fine in CPython 2.4.1; need to try it in 2.2 but methinks this is a bug in Jython. Will explore.

>but in the end that's pretty much an implementation detail and doesn't
>really matter for os.path users assuming that everything works.
And that's my point. javapath provides a "Java-centric" view of os.path.
Is that what people expect?

Again, this comes back to the fundamental question:

  Are people using Java to write Windows/AIX/Mac/... applications,
  or are people using Windows/... to write Java applications?

os.path=javapath is right for the latter, and wrong for the former.

I am in the former camp. I write code that routinely has to run on AIX, HP-UX, Solaris, Linux and Windows, so portability is a good thing, but I also prefer Python's model over Java's -- I like having access to platform-specific details, when I so choose. I've dealt with os.name and sys.platform and the rest often enough, when needed, and find the Python portability model to be simple and effective - and equally simple and unobtrusive when I *don't* care about writing portable code.


Assuming import ntpath and import javapath not working today are simply bugs to fix and not a feature, 'twould appear best to make os.path=nativepath:
1. Default behavior is comparable to CPython
2. Default behavior is what people using-Java-to-write-Win/etc-apps expect and prefer
3. People using-Win/etc-to-write-Java-apps can get _their_ desired behavior by 'import javapath'
4. This also happens to work much like IronPython; IP provides its own libraries (.NET Framework), but if you point it to the CPython libraries *you get CPython library behavior*. IronPython actually provides *better* Python compatibility than Jython does using os.path=javapath.

#4 particularly bothers me.
There is no 'spec' for Python; the closest thing we have is CPython's documentation and, to a lesser degree, CPython's implementation (including source code comments). IronPython does it right, IMO - a module with the same name as CPython should act like CPython (as much as possible). Would you find it bothersome or troubling if IronPython provide the string or _winreg modules with different behaviors and footprints than CPython's? What if IronPython provided a module called "re" that supported regular expressions, but not the same notation as CPython's? Would that bother you?


Jython should be compatible with CPython as much as possible.
Provide *extensions*, yes, excellent idea, but not gratuitous incompatibilities.

I see no problem - quite the opposite - with Jython provide *additional* modules, so whether it's called javapath or jython.os.path or whatever is, IMO, a *good* idea.

But Jython should not provide the same symbols as CPython with different behavior.


>If you think dividing is something that must be done
I don't. I have no qualms with javapath as-is, actually.
Well, it'd be nicer if it was _richer_, actually, but no, I see no need to change or splinter javapath.
Just don't call it os.path.

>Setting up Jython development environment is pretty simple using guide at [1]
Thanks for the tip, I hadn't seen that but yes it doesn't look too painful.

The os.path fix is quite easy actually, since it's just 1 source file.
I'll submit a patch for it as per [1]