Re: [Jython-dev] uname

[Jim B. <jim...@py...>]

On Wed, Aug 17, 2016 at 9:22 AM, Stefan Richthofer <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 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 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