uname

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

uname

Stefan Richthofer
Hey all,

some months ago I added an implementation of os.uname to posix-module. In a portable fashion and with some extra effort I made this also work on Windows, because I liked the idea of Jython being resilient enough to support this posix-feature no matter if the platform was actually posix or not.

Now I became aware of platform.uname, which I think is intended to work in such a portable manner, while os.uname should reflect system's uname in low-level sense. Indeed, also CPython features a Windows-equivalent of uname in platform.uname. Actually their approach wasn't too different to my re-invention of it in Jython's os.uname. With commit 9252c93e85754d6f3056407d3a67ae7633bdf813 I ensured that Jython's os.uname and also platform.uname match CPython's platform.uname on Windows exactly. (Can't use original CPython os.platform implementation, because it uses win32 module.)

But...
Jython's platform.uname used to report JVM-info:
('Java', 'stefan-x200', '1.8.0_101', 'Java HotSpot(TM) 64-Bit Server VM, 25.101-b13, Oracle Corporation', '', '')
I already broke this behavior by adding os.uname, because inserting JVM-info is only a fallback if os.uname is not available to back os.platform:

Jython 2.7.1b3
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_101
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, platform
>>> os.uname()
('Linux', 'stefan-x200', '3.16.0-4-amd64', '#1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)', 'x86_64')
>>> platform.uname()
('Linux', 'stefan-x200', '3.16.0-4-amd64', '#1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)', 'x86_64', '')
>>> exit()

You can still restore the old behavior by deleting os.uname (must be done before first call to platform.uname because of caching):

Jython 2.7.1b3
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_101
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, platform
>>> del os.uname
>>> platform.uname()
('Java', 'stefan-x200', '1.8.0_101', 'Java HotSpot(TM) 64-Bit Server VM, 25.101-b13, Oracle Corporation', '', '')
>>>

Now I wonder whether this was the right choice. Also: Maybe Jython should not support os.uname on Windows; e.g. code in platform.py checks platform by looking if os.uname gives an attribute-error.
However I'd like to learn about your opinions on this (if you care at all), maybe we could even have a vote.
Does someone have or know an actual use-case needing os.platform to provide JVM-info?

Current behavior:
- Never return JVM-info (is to some extend still available via platform.java_ver())
- os.uname and platform.uname behave equal (except that platform.uname appends processor info)
- os.uname is also implemented on Windows, equally to platform.uname in common result-elements

Note that it is a no-opt to let os.uname provide JVM-info instead of platform-info, because native extensions as supported bY JyNI look at these values to condition on underlying platform (observed in PyOpenGL). This was the original reason why I needed to add os.uname support at all.

top 1)
Should platform.uname be reverted to provide JVM-info, or should it be kept as it is now?

top 2)
Should os.uname be workable on Windows?
If not, what should it do?

a) throw NotImplementedError or return PyNotImplemented
(the 'right' way, but not what CPython-code would expect)
b) throw AttributeError
(satisfying typical checks for am-I-on-Windows/non-posix, unless someone uses hasattr(os, 'uname'))
c) Somehow truly remove os.uname on Windows (What would be the best way to achieve this?)
(would precisely resemble CPython-behavior, including hasattr(os, 'uname'))


Best

Stefan

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: uname

Jeff Allen-2
There's an argument that the *platform* of Jython is Java. Sometimes you
want a clue about how the file system works (e.g. is "C:\" meaningful)
and sometimes you want to guess what functions are available (as in the
"Avaliability:" note in the documentation of the os module). It's not
very clear (I'm looking at the 3.5.2 docs), of the several ways to
interrogate os or platform, which is to be used as a clue for what purpose.

It seems clear platform.uname should be consistent with platform.system,
platform.note, 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.

Jeff Allen

On 14/08/2016 04:26, Stefan Richthofer wrote:

> Hey all,
>
> some months ago I added an implementation of os.uname to posix-module. In a portable fashion and with some extra effort I made this also work on Windows, because I liked the idea of Jython being resilient enough to support this posix-feature no matter if the platform was actually posix or not.
>
> Now I became aware of platform.uname, which I think is intended to work in such a portable manner, while os.uname should reflect system's uname in low-level sense. Indeed, also CPython features a Windows-equivalent of uname in platform.uname. Actually their approach wasn't too different to my re-invention of it in Jython's os.uname. With commit 9252c93e85754d6f3056407d3a67ae7633bdf813 I ensured that Jython's os.uname and also platform.uname match CPython's platform.uname on Windows exactly. (Can't use original CPython os.platform implementation, because it uses win32 module.)
>
> But...
> Jython's platform.uname used to report JVM-info:
> ('Java', 'stefan-x200', '1.8.0_101', 'Java HotSpot(TM) 64-Bit Server VM, 25.101-b13, Oracle Corporation', '', '')
> I already broke this behavior by adding os.uname, because inserting JVM-info is only a fallback if os.uname is not available to back os.platform:
>
> Jython 2.7.1b3
> [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_101
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import os, platform
>>>> os.uname()
> ('Linux', 'stefan-x200', '3.16.0-4-amd64', '#1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)', 'x86_64')
>>>> platform.uname()
> ('Linux', 'stefan-x200', '3.16.0-4-amd64', '#1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)', 'x86_64', '')
>>>> exit()
> You can still restore the old behavior by deleting os.uname (must be done before first call to platform.uname because of caching):
>
> Jython 2.7.1b3
> [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_101
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import os, platform
>>>> del os.uname
>>>> platform.uname()
> ('Java', 'stefan-x200', '1.8.0_101', 'Java HotSpot(TM) 64-Bit Server VM, 25.101-b13, Oracle Corporation', '', '')
> Now I wonder whether this was the right choice. Also: Maybe Jython should not support os.uname on Windows; e.g. code in platform.py checks platform by looking if os.uname gives an attribute-error.
> However I'd like to learn about your opinions on this (if you care at all), maybe we could even have a vote.
> Does someone have or know an actual use-case needing os.platform to provide JVM-info?
>
> Current behavior:
> - Never return JVM-info (is to some extend still available via platform.java_ver())
> - os.uname and platform.uname behave equal (except that platform.uname appends processor info)
> - os.uname is also implemented on Windows, equally to platform.uname in common result-elements
>
> Note that it is a no-opt to let os.uname provide JVM-info instead of platform-info, because native extensions as supported bY JyNI look at these values to condition on underlying platform (observed in PyOpenGL). This was the original reason why I needed to add os.uname support at all.
>
> top 1)
> Should platform.uname be reverted to provide JVM-info, or should it be kept as it is now?
>
> top 2)
> Should os.uname be workable on Windows?
> If not, what should it do?
>
> a) throw NotImplementedError or return PyNotImplemented
> (the 'right' way, but not what CPython-code would expect)
> b) throw AttributeError
> (satisfying typical checks for am-I-on-Windows/non-posix, unless someone uses hasattr(os, 'uname'))
> c) Somehow truly remove os.uname on Windows (What would be the best way to achieve this?)
> (would precisely resemble CPython-behavior, including hasattr(os, 'uname'))
>
>
> Best
>
> Stefan
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> Jython-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: uname

Stefan Richthofer
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.

(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.)

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).

Best

Stefan


> Gesendet: Sonntag, 14. August 2016 um 23:28 Uhr
> Von: "Jeff Allen" <[hidden email]>
> An: [hidden email]
> Betreff: Re: [Jython-dev] uname
>
> There's an argument that the *platform* of Jython is Java. Sometimes you
> want a clue about how the file system works (e.g. is "C:\" meaningful)
> and sometimes you want to guess what functions are available (as in the
> "Avaliability:" note in the documentation of the os module). It's not
> very clear (I'm looking at the 3.5.2 docs), of the several ways to
> interrogate os or platform, which is to be used as a clue for what purpose.
>
> It seems clear platform.uname should be consistent with platform.system,
> platform.note, 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.
>
> Jeff Allen
>
> On 14/08/2016 04:26, Stefan Richthofer wrote:
> > Hey all,
> >
> > some months ago I added an implementation of os.uname to posix-module. In a portable fashion and with some extra effort I made this also work on Windows, because I liked the idea of Jython being resilient enough to support this posix-feature no matter if the platform was actually posix or not.
> >
> > Now I became aware of platform.uname, which I think is intended to work in such a portable manner, while os.uname should reflect system's uname in low-level sense. Indeed, also CPython features a Windows-equivalent of uname in platform.uname. Actually their approach wasn't too different to my re-invention of it in Jython's os.uname. With commit 9252c93e85754d6f3056407d3a67ae7633bdf813 I ensured that Jython's os.uname and also platform.uname match CPython's platform.uname on Windows exactly. (Can't use original CPython os.platform implementation, because it uses win32 module.)
> >
> > But...
> > Jython's platform.uname used to report JVM-info:
> > ('Java', 'stefan-x200', '1.8.0_101', 'Java HotSpot(TM) 64-Bit Server VM, 25.101-b13, Oracle Corporation', '', '')
> > I already broke this behavior by adding os.uname, because inserting JVM-info is only a fallback if os.uname is not available to back os.platform:
> >
> > Jython 2.7.1b3
> > [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_101
> > Type "help", "copyright", "credits" or "license" for more information.
> >>>> import os, platform
> >>>> os.uname()
> > ('Linux', 'stefan-x200', '3.16.0-4-amd64', '#1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)', 'x86_64')
> >>>> platform.uname()
> > ('Linux', 'stefan-x200', '3.16.0-4-amd64', '#1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)', 'x86_64', '')
> >>>> exit()
> > You can still restore the old behavior by deleting os.uname (must be done before first call to platform.uname because of caching):
> >
> > Jython 2.7.1b3
> > [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_101
> > Type "help", "copyright", "credits" or "license" for more information.
> >>>> import os, platform
> >>>> del os.uname
> >>>> platform.uname()
> > ('Java', 'stefan-x200', '1.8.0_101', 'Java HotSpot(TM) 64-Bit Server VM, 25.101-b13, Oracle Corporation', '', '')
> > Now I wonder whether this was the right choice. Also: Maybe Jython should not support os.uname on Windows; e.g. code in platform.py checks platform by looking if os.uname gives an attribute-error.
> > However I'd like to learn about your opinions on this (if you care at all), maybe we could even have a vote.
> > Does someone have or know an actual use-case needing os.platform to provide JVM-info?
> >
> > Current behavior:
> > - Never return JVM-info (is to some extend still available via platform.java_ver())
> > - os.uname and platform.uname behave equal (except that platform.uname appends processor info)
> > - os.uname is also implemented on Windows, equally to platform.uname in common result-elements
> >
> > Note that it is a no-opt to let os.uname provide JVM-info instead of platform-info, because native extensions as supported bY JyNI look at these values to condition on underlying platform (observed in PyOpenGL). This was the original reason why I needed to add os.uname support at all.
> >
> > top 1)
> > Should platform.uname be reverted to provide JVM-info, or should it be kept as it is now?
> >
> > top 2)
> > Should os.uname be workable on Windows?
> > If not, what should it do?
> >
> > a) throw NotImplementedError or return PyNotImplemented
> > (the 'right' way, but not what CPython-code would expect)
> > b) throw AttributeError
> > (satisfying typical checks for am-I-on-Windows/non-posix, unless someone uses hasattr(os, 'uname'))
> > c) Somehow truly remove os.uname on Windows (What would be the best way to achieve this?)
> > (would precisely resemble CPython-behavior, including hasattr(os, 'uname'))
> >
> >
> > Best
> >
> > Stefan
> >
> > ------------------------------------------------------------------------------
> > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> > patterns at an interface-level. Reveals which users, apps, and protocols are
> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > planning reports. http://sdm.link/zohodev2dev
> > _______________________________________________
> > Jython-dev mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/jython-dev
> >
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> Jython-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

------------------------------------------------------------------------------
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: uname

Jim Baker-2
On Wed, Aug 17, 2016 at 9:22 AM, Stefan Richthofer <[hidden email]> 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


------------------------------------------------------------------------------

_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: uname

Jeff Allen-2
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
> <[hidden email] <mailto:[hidden email]>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: uname

Darjus Loktevic
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 <[hidden email]> 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
> <[hidden email] <mailto:[hidden email]>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------

_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: uname

Jeff Allen-2
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 <[hidden email]
> <mailto:[hidden email]>> 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
>     > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>> 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
>     [hidden email]
>     <mailto:[hidden email]>
>     https://lists.sourceforge.net/lists/listinfo/jython-dev
>


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