Repository navigation
Consider deprecating platform.java_ver because it is only helpful for Jython #116349
Description
Activity
Jython is still maintained. Is there a chance that if they do add Python 3 compatibility one day, they'll ask for this function to be added back? It doesn't look hugely out of place with the other functions in the
platformmodule, and we've accepted lots of PRs in recent years so that Python can run with fewer patches on platforms such as WASI, iOS and Android. On the Jython project's README, it says:watch this space for a 3.x version
On Discord, you mentioned that this function might be confusing for users. Do we have evidence of users being confused by it?
Some but not much use in the top 8k PyPI projects:
❯ python3 ~/github/misc/cpython/search_pypi_top.py -q . "\bjava_ver\b" Found existing alias for "python3". You should use: "p3" ./clvm_rs-0.6.0.tar.gz: clvm_rs-0.6.0/venv/lib/python3.7/site-packages/pkg_resources/_vendor/appdirs.py: os_name = platform.java_ver()[3][0] ./appdirs-1.4.4.tar.gz: appdirs-1.4.4/appdirs.py: os_name = platform.java_ver()[3][0] ./jc-1.25.1.tar.gz: jc-1.25.1/jc/appdirs.py: os_name = platform.java_ver()[3][0] ./jedi-0.19.1.tar.gz: jedi-0.19.1/jedi/third_party/typeshed/stdlib/2/platform.pyi: def java_ver(release=..., vendor=..., vminfo=..., osinfo=...): ... ./jedi-0.19.1.tar.gz: jedi-0.19.1/jedi/third_party/typeshed/stdlib/3/platform.pyi: def java_ver( ./magicgui-0.8.1.tar.gz: magicgui-0.8.1/src/magicgui/_util.py: os_name = platform.java_ver()[3][0] ./mypy-1.8.0.tar.gz: mypy-1.8.0/mypy/typeshed/stdlib/platform.pyi: def java_ver( ./pex-2.2.1.tar.gz: pex-2.2.1/pex/vendor/_vendored/pip/pip/_vendor/appdirs.py: os_name = platform.java_ver()[3][0] ./pex-2.2.1.tar.gz: pex-2.2.1/pex/vendor/_vendored/setuptools/pkg_resources/_vendor/appdirs.py: os_name = platform.java_ver()[3][0] ./Nuitka-2.0.3.tar.gz: Nuitka-2.0.3/nuitka/build/inline_copy/appdirs/appdirs.py: os_name = platform.java_ver()[3][0] ./pyinstrument-4.6.2.tar.gz: pyinstrument-4.6.2/pyinstrument/vendor/appdirs.py: os_name = platform.java_ver()[3][0] ./prometheus_client-0.20.0.tar.gz: prometheus_client-0.20.0/prometheus_client/platform_collector.py: java_version, _, vminfo, osinfo = self._platform.java_ver() ./prometheus_client-0.20.0.tar.gz: prometheus_client-0.20.0/tests/test_platform_collector.py: def java_ver(self): ./numba-0.59.0.tar.gz: numba-0.59.0/numba/misc/appdirs.py: os_name = platform.java_ver()[3][0] ./pyLDAvis-3.4.1.tar.gz: pyLDAvis-3.4.1/pyLDAvis/lib/python3.11/site-packages/pkg_resources/_vendor/appdirs.py: os_name = platform.java_ver()[3][0] ./Pint-0.23.tar.gz: Pint-0.23/pint/_vendor/appdirs.py: os_name = platform.java_ver()[3][0] ./pymongo-4.6.2.tar.gz: pymongo-4.6.2/pymongo/pool.py: _name, _ver, _arch = platform.java_ver()[-1] ./pytype-2024.2.13.tar.gz: pytype-2024.2.13/pytype/typeshed/stdlib/platform.pyi: def java_ver( ./pyre-check-0.9.19.tar.gz: pyre-check-0.9.19/typeshed/stdlib/platform.pyi: def java_ver( ./seaborn-0.13.2.tar.gz: seaborn-0.13.2/seaborn/external/appdirs.py: os_name = platform.java_ver()[3][0] ./utilmy-0.1.17078128.tar.gz: utilmy-0.1.17078128/utilmy/configs/util_dirs.py: os_name = platform.java_ver()[3][0] ./typeshed_client-2.4.0.tar.gz: typeshed_client-2.4.0/typeshed_client/typeshed/platform.pyi: def java_ver( Time: 0:00:42.010103 Found 22 matching lines in 19 projects
11/22 are appdirs or vendored appdirs code. Its successor platformdirs has removed this code.
- Hard to know how much depends on this code.
7/22 are type stubs or similar.
The remaining 4 are:
./magicgui-0.8.1.tar.gz: magicgui-0.8.1/src/magicgui/_util.py: os_name = platform.java_ver()[3][0] ./prometheus_client-0.20.0.tar.gz: prometheus_client-0.20.0/prometheus_client/platform_collector.py: java_version, _, vminfo, osinfo = self._platform.java_ver() ./pymongo-4.6.2.tar.gz: pymongo-4.6.2/pymongo/pool.py: _name, _ver, _arch = platform.java_ver()[-1] ./utilmy-0.1.17078128.tar.gz: utilmy-0.1.17078128/utilmy/configs/util_dirs.py: os_name = platform.java_ver()[3][0]
Reacted by sobolevn and C.A.M. Gerlachwe've accepted lots of PRs in recent years so that Python can run with fewer patches on platforms such as WASI, iOS and Android
This is different,
java_veris not about Java platform or any other platform that we run CPython on, it is specific for another language implementation - Jython.watch this space for a 3.x version
I hope that this release will happen! Having Python in Java's ecosystem is great.
But, there are other implementations that do share our stdlib. Two comments:- they don't have any special cases in our stdlib
- they have to share this property as well, example: https://github.com/RustPython/RustPython/blob/d0c827ed3837ca8dfde07063f8591878fa06bd57/Lib/platform.py#L466
We don't even document
javato be a part ofsys.platform:.. c:function:: const char* Py_GetPlatform() .. index:: single: platform (in module sys) Return the platform identifier for the current platform. On Unix, this is formed from the "official" name of the operating system, converted to lower case, followed by the major revision number; e.g., for Solaris 2.x, which is also known as SunOS 5.x, the value is ``'sunos5'``. On macOS, it is ``'darwin'``. On Windows, it is ``'win'``. The returned string points into static storage; the caller should not modify its value. The value is available to Python code as ``sys.platform``.Do we have evidence of users being confused by it?
Me 😆
I can also find some code that looks suspicious to me in some rather popular projects:
See also:
- Deprecate / remove os.name=java #90613
- Which Jython version works with Python 3.9 jython/jython#312 for recent discussion about 3.x support in Jython (summary: no timeline)
And ping @jeff5 from Jython.
Reacted by sobolevnI consider my initial concerns to have been addressed, FWIW — thanks!
Reacted by sobolevn❯ python3 ~/github/misc/cpython/search_pypi_top.py -q . "\bjava_ver\b" ... ./jedi-0.19.1.tar.gz: jedi-0.19.1/jedi/third_party/typeshed/stdlib/3/platform.pyi: def java_ver(Usually, I remove manually
.pyifiles from a code search. Maybe I should modify my tool to ignore them by default? Removing the function is not going to "break" type annotations of PYI files.Sorry, I'm without access to a decent computer that would let me make fully informed contribution to the discussion. The idea that Java is a sort of os.name has been a source of problems. It should be possible within the platform module to determine the implementation name (PyPy etc.). Then knowing it is Jython, to ask the version of Java through Java API (I think). Ping @Stewori to check my logic.
@jeff5: The question here is only if removing "Java/Jython code" from CPython is causing any trouble to Jython. Obviously, Jython is free to patch the
platformmodule,os.name, etc. to behave differently than CPython. It would be very surprised if Jython has no change on the stdlib :-)I don't see why CPython has to maintain "Jython support" outside its test suite. In the test suite, we should try to have the same code on all Python implementations. But it's rare to get freeback from Jython or PyPy about the test suite :-(
One more detail.
java_veruses this API:def _java_getprop(name, default): from java.lang import System try: value = System.getProperty(name) if value is None: return default return value except AttributeError: return default
which is Jython's internal API, I guess. It is clearly untested in CPython and can be changed by a 3rd party at any moment.
I think @jeff5 's latest comment summarizes it well.
It should be clarified thatjava_veris not to support Jython or needed by Jython (it uses a shaded STL) but is a service to libraries/applications/users to access that information within official Python API. AFAIK it was introduced as part of a roadmap to an implementation-independent Python STL, which we now know has been failed to achieve. IMO, a more generic namevm_veror so would have been a better choice since it could have also hosted e.g. .net version for IronPython. Such a generic name would likely not be disputed for deprecation now.The "java" os name indeed caused more trouble to Jython than benefit. Libraries that check
os.namein order to implement platform-specific behavior most usually have a dysfunctional fallback for that case, even though often enough their behavior for the original platform name would have actually worked well also in Jython case. We had to apply some serious trickery to work around that issue, but we hesitated to change that spec since it is part of the reference STL. The plan was to apply that change with the major version 3.So, from Jython perspective, I would say these values are already deprecated in the 3.x-branch (actually plainly removed).
So the deprecation attempt is actually overdue (retrospectively speaking, should have been part of the entire 3.x-STL, if that information had been available earlier).I'm curious, what's the progress on Jython port to Python 3?
The thing is, it is not just a port, but a redesign (of the core, at least) to incorporate lessons learned, address technical debt and take advantage of new Java features. A major version increment is a unique opportunity for such a breaking redesign. Jython 3 has to deal not only with Python progress, but also with Java progress. At the same time, some continuation with the Jython 2 sources shall be kept to reuse code where feasible and to retain the project's history and attributions. @jeff5 is doing a fantastic job with the redesign, but progress is naturally slow due to limited resources and difficulty of the challenge. See https://www.jython.org/jython-3-mvp, https://www.jython.org/jython-3-roadmap and https://the-very-slow-jython-project.readthedocs.io/en/latest/ for details or get in touch on the jython-dev mailing list.
Reacted by Kirill Podoprigora7 remaining items
I did, but I also did not get the impression that the purpose of having this support in the platform module was being understood.
Scripts that work on multiple Python platforms may still want to access the Java version in a cross-platform way and deprecation of the support will break this. E.g. uname() will stop returning useful information on Jython. Same for platform().
Hmm, it would have been nice to ask a review from me as (one of the) platform module authors and maintainer before merging the PR.
By the way, since you have been inactive for the past decade, it didn't occur to me to ping you on the issue. (I'm still mentoring somehow @sobolevn after he got promoted.)
Hmm, it would have been nice to ask a review from me as (one of the) platform module authors and maintainer before merging the PR.
Sorry, I didn't know that you maintain this module!
I think you might want to add yourself to https://github.com/python/cpython/blob/main/.github/CODEOWNERS This way you can be automatically notified on all
Lib/platform.pychanges :)It would be easier for new devs to know who to ask as well.
The interface java_ver() uses is the same as most other APIs in the platform module. I don't see how this could be confusing.
I don't quite understand this part. In my mind, it is different, because it uses
import java.langwhich is not the part of CPython. So, right now it basically does nothing (especailly considering the fact that Jython3 does not exist right now).It is being used in the platform module itself for uname() and platform().
Yes, this is the second step: to deprecate
Javaplatform, because right now we havesys.implementationwhich can showJythonorCPythonor any other alternative implementation.Right now
java_veris used there, but it is never doing any useful work, because again, it usesimport java.langconstruct.By the way, since you have been inactive for the past decade,..
I have not actively worked on code changes, but have been rather active in discussions, reviews and guiding other devs, including yourself.
I think you might want to add yourself to https://github.com/python/cpython/blob/main/.github/CODEOWNERS This way you can be automatically notified on all
Lib/platform.pychanges :)Indeed, I should add myself there. It didn't occur to me that I wasn't listed in that file, since I am listed for the platform module in https://devguide.python.org/core-developers/experts/
I don't quite understand this part. In my mind, it is different, because it uses
import java.langwhich is not the part of CPython. So, right now it basically does nothing (especailly considering the fact that Jython3 does not exist right now).Right. Like I said: this code was added for Jython, so would only be used on that platform (or any other Java implementation where Python runs).
The key point is that the platform module defines an API which should continue working on other implementations as well. If Jython decides to vendor its own stdlib, and continue to support this API in their vendored copy, all is fine. OTOH, keeping the definition of the APIs in one place, does help a lot, since people writing cross-platform code can then expect this API to also work on other Python implementations.
Mark, there are many inactive and semi-inactive people listed in the experts file, so it was decided that codeowners would be an add-yourself or occasionally by-request file.
@malemburg , thx for the support and thorough consideration of other implementations' needs :)
As I pointed out earlier, Jython already maintains its own copy of the STL (the python-written part).
In the early days it may have workd with the original CPython stl files, but that hasn't been the case any more for a while (since somewhen before I joined the project).
The shaded stl was once a regularly updated patched copy of the stl but that became infeasible because CPython was changing it too rapidly to keep up with fixing the breakage (just speaking about the 2.x branch). So we ended up updating only cherry-picked parts, e.g. in security-critical cases or if new features could be adopted smoothely.Jython 3 may start over with a new attempt to use the original STL, but those decisions are still to be made, because the redesigned core is not yet sufficiently mature to tackle STL.
However, the decision to discard
os.name=='java'has been made since it was a constant source of trouble. Too many lib maintainers implement a completely dysfunctional fallback (dummy code that just fails fast with some error message "unsupported platform") ifos.nameis not from a small list of known values, usually not aware of Jython. We had to monkeypatch such barriers away for some crucial libs because the issue propagated through the dependency tree of too many other libs, making crucial stuff (I think even pip) unworkable.API/interface considerations: I still think it would be good to have some hook in the platform module where users can obtain the information that java_ver used to provide within official Python API. I agree that
java_veris too specific since the platform module generally has specific x_ver functions only for platforms addressed by CPython.I suggest to consider adding some general version function that can (optionally) be implemented by alternative Python implementations to provide version information of the running vm or middleware if applicable.
Jython would return the tuple similar to java_ver, IronPython can provide some similar info about the .net version and e.g. a browser-based Python could provide the browser name, version, etc. info. Pythons that do not run on a middleware would return an empty tuple or some other well-defined default value for that case.
Name could bevm_verormiddleware_veror something. Such a hook would be useful independently from Jython 3 availability. Would such a change require a PEP? (Removing java_ver apparently does not.)keeping the definition of the APIs in one place, does help a lot, since people writing cross-platform code can then expect this API to also work on other Python implementations.
I come from RustPython background, where some extra APIs are also present. For example, RustPython was the first Python implementation to support WASM builds. But, I think that it was intergrated smoothly: there was a clear separation of "this is CPython's regular APIs" and "this is our own RustPython's ones that only exist and make sense here".
I don't think that anybody would accept a
rust_verfunction toplatform.pythese days.The java_ver() API was added specifically for Jython, since at the time it reused the Python stdlib, similiar to how IronPython also reused it
This is once again an argument to deprecate it.
java_verfunction that returns a version ofC#? Very confusing.or any other Java implementation where Python runs
This is indeed a thing for other platforms, like GraalVM: https://www.graalvm.org/latest/reference-manual/python/Jython/
But, again, it has lots of notes about how unsupported of all this is, quotes:
- Most Jython code that uses Java integration will be based on a stable Jython release, and these only come in Python 2.x versions. GraalPy, in contrast, is only targeting Python 3.x. GraalPy does not provide full compatibility with these earlier 2.x versions of Jython. Thus, a significant migration step will have to be taken to migrate all your code to Python 3.
- Note that some features of Jython have a negative impact on runtime performance, and are disabled by default. To make migration easier, you can enable some features using a command line option:
--python.EmulateJython. - Additionally, importing Java packages as Python modules is only supported under very specific circumstances.
I tried this locally, but GraalVM does not support m2 macs, so I will call it a failure :(
Here's my docker output:
» docker run --rm -it ghcr.io/graalvm/graalpy-community sh WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested sh-5.1# graalpy Python 3.10.8 (Mon Jan 08 10:59:17 UTC 2024) [Graal, GraalVM CE, Java 21.0.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os, platform >>> print(1, os.uname()) 1 posix.uname_result(sysname='Linux', nodename='d71df3245931', release='5.15.49-linuxkit', version='#1 SMP PREEMPT Tue Sep 13 07:51:32 UTC 2022', machine='x86_64') >>> print(2, platform.uname()) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/opt/graalpy-23.1.2/lib/python3.10/collections/__init__.py", line 441, in __repr__ return self.__class__.__name__ + repr_fmt % self TypeError: not all arguments converted during string formatting >>> print(3, platform.platform()) 2 3 Linux-5.15.49-linuxkit-x86_64-with-glibc2.16 >>> print(4, platform.java_ver()) 4 ('21.0.2', 'GraalVM Community', ('Substrate VM', '21.0.2+13', 'GraalVM Community'), (None, None, None))
So, it can work on GraalVM as well, due to the fact that
import java.langis emulated there.
But, when working with GraalVM they have lots of other support packages (likepolyglot). I think adding an extra function there would be more helpful: they can test it at least. Unlike us. Or using a future proposed API instead.The
TypeErrorabove clearly demostrates my point: if we don't test something, we cannot claim to support it in the long run.Also notice the
(None, None, None)part, which does not follow the docs:Values which cannot be determined are set to the defaults given as parameters (which all default to '').And the last thing: it does not use
Javaas itssystemattribute, which would be important later.All in all, this looks like a source of trouble, rather than a source of truth.
Let's work on a better API instead :)@Stewori Thanks a lot for the feedback!
I suggest to consider adding some general version function that can (optionally) be implemented by alternative Python implementations to provide version information of the running vm or middleware if applicable.
This is a good idea, I fully support this. It can be just empty in
CPythonand returnNone, RustPython can returnrustcversion, Jython can returnjavacversion, etc.I think that it would require a PEP 👍
Reacted by C.A.M. GerlachI took a look at PEP 1 and conclude from
Most enhancements and bug fixes don’t need a PEP and can be submitted directly to the Python issue tracker.
that a PEP would likely be an overkill for the proposed enhancement. So, here we go (worth a try).
Related discussion about deprecating 'Java' as platform.system(): https://discuss.python.org/t/lets-deprecate-platform-system-java/48026
The second step after deprecating
java_ver🎉 😄If this reply seems terse it's because of device limitations not mood. For the same reason I'm unable to read up on the Python API as I'd like.
As long as the stdlib provides a standard way to detect Jython, one can ask everything else via specific API in code guarded by the test.
Accepted os.name is for questions about the file system not the Python implementation.
One needs to discover Jython, not just Java, since as the Graal quote shows, not all implementations allow you to ask the next question (e.g. Java version) the same way. A common way to discover Java and its version might be useful but I can't immediately identify a use case. (What could I do without also knowing it's Jython?)
@jeff5 I assume Jython can still be discovered via
sys.implementationas @sobolevn has pointed out (the implementation would have to change though, not relying onjava_verany more). Then, there is alsoplatform.python_implementationwhich provides the same, apparently.I don't see why CPython has to maintain "Jython support" outside its test suite.
Nor me. I think that Python only has to maintain support for the possibility of other implementations than CPython. But I think that is satisfied already by being able to ask the implementation, and the places (mainly tests) where the stdlib guards on the outcome.
It is welcome not to have to have to maintain variants of a large module just to exclude a small implementation-specific method. But I expect we can contribute to that.
Feature or enhancement
What do you think about deprecating
platform.java_ver? It is never used on CPython, it is a helper forJythononly, which is basically stuck on 2.7 for the last 10 years.I think that we should deprecate and remove such compat parts with tools that no longer exist. In the future Jython can add its own implementation to its own stdlib, if ever.
cpython/Lib/platform.py
Lines 516 to 547 in a29998a
I propose to depreacate / remove it in 3.13 / 3.15
Linked PRs
platform.java_verfunction #116471