Re: uname

No problem with the established consensus on os.name, which I believe to 
be that we are stuck with "java" until Jython 3.x.

I believe we need to express three dimensions here:

 1. what to expect about the names of files. This should be os.name, but
    make do with os._name until 3.x.
 2. what to expect from the real machine.
 3. what virtual machine (or runtime)  is executing my code. The type
    should be platform.python_implementation().

Now, the answer to question 2 will be assumed by programmers coming from 
CPython to be platform.system and the first element of the result of 
platform.uname(). The documentation explicitly allows "Java" as a 
legitimate value 
(https://docs.python.org/3/library/platform.html#platform.system). My 
first answer to Stefan was based on that documentation.

But now I think this is to repeat the mistake we made with os.name, and 
the documentation hint is wrong: it were better platform.system gave you 
the OS underneath. You have a couple of other ways to find out it's Java 
or Jython. If I'm right about this, maybe platform.system should remain 
consistent with os.name; or maybe it should take the noble course from 
the start.

Jeff

Jeff Allen

On 19/08/2016 03:24, Darjus Loktevic wrote:
> 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 <[email protected] 
> <mailto:[email protected]>> 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 <http://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
>     <http://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 <http://platform.name>
>     rather than os.name <http://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
>     > <[email protected] <mailto:[email protected]>
>     <mailto:[email protected]
>     <mailto:[email protected]>>> 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>
>     <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> <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
>     [email protected]
>     <mailto:[email protected]>
>     https://lists.sourceforge.net/lists/listinfo/jython-dev
>


------------------------------------------------------------------------------
_______________________________________________
Jython-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-dev