Re: [Jython-dev] uname

[Darjus L. <da...@gm...>]

Agreed,

Let's make this change in Jython3. We really cannot break this for Jython2.

On Thu, Aug 18, 2016 at 3:49 PM Jeff Allen <ja...@fa...> wrote:

> 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
> >
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>