Message11105

Maybe you're right. Let me make one more point for the fallbacks:
One could say that Jython's platform is Java and so the wrapper can be a bit more portable.

On the other hand in strict sense the posix module shouldn't be available then anyway: Java isn't posix, is it?

I looked into JNR, which backs the posix module and they also have the option to use a purely Java-backed posix. So in that sense Java actually is posix. Its getlogin wrapper is in turn bakced by getlogin() in https://github.com/jnr/jnr-posix/blob/master/src/main/java/jnr/posix/JavaLibCHelper.java, which plainly uses System.getProperty("user.name").

If we changed
private static final POSIX posix = POSIXFactory.getPOSIX(posixHandler, true);
into
private static final POSIX posix = POSIXFactory.getJavaPOSIX(posixHandler, true);

this would force using the Java backend, yielding the same behavior as the proposed fallbacks.
However, compared to this I would still prefer the fallbacks, because System.getenv("LOGNAME")/System.getenv("USER") is said to be more reliable than os.user property.

All in all I'd say we'd better include the fallbacks if there is some (major?) framework affected by this. If it's 'only' enduser code the endusers should better move on to a more suitable solution as suggested in https://docs.python.org/2/library/os.html#os.getlogin.

Patrick: What is your view on this?

I also wonder how this can have worked in Jython 2.2.1. Maybe PosixModule has been rewritten since then and they had the System.property variant in old days.

Finally, I don't like the error message. That could be improved. Downside here is that CPython's variant isn't ideal either, so I see no point in reproducing that one. I suppose they also just put through some original cause that wasn't especially caught. Anyway, maybe we could still improve on that point? Suggestions?