Re: [Jython-dev] uname

[Jeff A. <ja...@fa...>]

I agree with all this. As I said initially:

It seems clear platform.uname should be consistent with platform.system,
platform.node, and so on. The documentation of platform.system
explicitly mentions 'Java' as an expected return. Not clear that it
should be consistent with os.uname.

I also agree it is a pain that os.name should not reflect the real "disk 
operating system" when so much code uses it like that. I think I saw 
that this change has already been made in Jython 3. (Did I dream it?)

However, I seem to observe (and it may be old code) that os.name gets 
used in two ways: in one place to decide what functions might be 
available, and in another to decide whether paths like "C:\Users" would 
be valid. These uses conflict when you throw in jnr-posix. Perhaps, 
against one's initial instincts, the availability of functions in the os 
module is best inferred from platform.name rather than os.name.

Jeff

Jeff Allen

On 17/08/2016 17:28, Jim Baker wrote:
> On Wed, Aug 17, 2016 at 9:22 AM, Stefan Richthofer 
> <Ste...@gm... <mailto:Ste...@gm...>> wrote:
>
>     Hey Jeff,
>     thanks for your reply!
>
>     I agree that in theory, os.uname and platform.uname should be
>     consistent.
>     And also platform.system with uname. However in practice, IMO it
>     would cause much less trouble with not-Jython-aware modules if
>     uname would provide native info rather than JVM-info. Jython-aware
>     modules can obtain JVM-info from platform.java_ver anyway. On the
>     other hand platform.uname always returned JVM-info in Jython until
>     now, so there might be Jython-aware code out there relying on this.
>     So as a compromise I'd suggest to let platform.uname behave like
>     it always used to and os.uname provide native info such that
>     non-Jython-aware modules have higher chance to work (especially
>     relevant in JyNI; I wouldn't want to monkeypatch this!). os.uname
>     should be save for existing Jython-aware modules, since it didn't
>     exist at all in Jython prior to 2.7.1.
>
>
> +1, let's make this distinction. Keep os.uname with the new change; 
> and make platform.uname go back to being Java information. This is why 
> we have the platform module, vs the os module.
>
> I would keep this distinction for Jython 3.
>
>
>     (It's already a constant pain that os.name <http://os.name> is
>     'java' and Alex Grönholm once pointed out in IRC this would switch
>     to CPython behavior in Jython 3. IIRC this currently breaks pip in
>     Jython on Windows. Maybe this can be fixed with a hack I use in
>     JyNI, but that's rather a story for Jython 2.7.2.)
>
>
> Agreed about the constant pain.
>
> If we had the chance to go back in time to fix this for 2.7.0, I would 
> have made os.name <http://os.name> be the underlying OS (eg 'posix' 
> instead of 'java'). The os module should be about the underlying OS - 
> it mostly is. So definitely we should fix for Jython 3.
>
>
>     Summary
>     If there are no objections I will make
>     - os.uname provide native platform info (for practicability)
>     - platform.uname provide JVM-info (for backward-compatibility)
>     We still need to more confidently decide how os.uname should
>     behave on Windows (however keeping current variant shouldn't be
>     too bad I suppose).
>
>
> +1
>
> Supporting os.uname on Windows make sense.
>
> - Jim
>