[Jython-dev] uname

[Stefan R. <Ste...@gm...>]

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