Description
Feature or enhancement
Proposal:
There exist alternative Python implementations that run on a virtual machine (vm) or a comparable middleware. The platform module currently lacks an implementation-independent API to retrieve (version-)information of an underlying vm. Examples are IronPython, Jython (3 possibly one day), RustPython. The proposal is to add a replacement for the recently deprecated function platform.java_ver under a generic name platform.vm_info that can optionally be implemented by a Python implementation. The return value of such a function would be a tuple inspired by what used to be returned by platform.java_ver.
The doc of that function states:
""" Version interface for Jython.
Returns a tuple (release, vendor, vminfo, osinfo) with vminfo being
a tuple (vm_name, vm_release, vm_vendor) and osinfo being a
tuple (os_name, os_version, os_arch).
Values which cannot be determined are set to the defaults
given as parameters (which all default to '').
"""IMO only the vm_info part should be returned by the propsed function platform.vm_info, hence the name. Os info should be obtainable from the os module, release should be obtainable similar to CPython's release. For vendor I do honestly not understand what the difference to vm_vendor would supposed to be.
As a consequence, I suggest the following definition:
def vm_info(vm_name='', vm_release='', vm_vendor=''):
""" Version interface for Python implementations on virtual machines.
Returns a tuple (vm_name, vm_release, vm_vendor).
Values which cannot be determined are set to the defaults
given as parameters (which all default to '').
""" Apparently, this is plainly the old java_ver refactured to the relevant subset.
This definition is merely intended as an entry point for discussion. E.g. I would be fine with a different naming etc. if as a result more use cases can be covered. E.g. I am not sure whether for RustPython the notion of a vm would be accurate, so a broader name may be suggested. Also the parameters vm_name, vm_release and vm_vendor are placed here for discussion. For Java this makes sense because there exists e.g. Java implementations by Oracle and IBM (and many more in fact), which is relevant to know besides the release version number. I am rather confident about the idea that a tuple should be returned and that a plain version number would be an insufficiently narrow information. Perhaps even more fields should be defined, e.g. the build-type of the vm.
As many maintainers of alternative Python implementations as possible should be noticed to take a look at this proposal to make sure it covers as many use cases as possible.
Note:
Most enhancements and bug fixes don’t need a PEP and can be submitted directly to the Python issue tracker. (from: PEP 1)
Given that with java_ver a special case of this proposal has already been part of Python STL for well over a decade, evidence demands the inevitable conclusion that a PEP would be an overkill for this proposal. Even if not, the discussion in this issue would be a necessary prerequisite for a PEP.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere