New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we maintain Jython related code? #82694
Comments
I can read some of Jython related code on the master branch. Can we get rid of the Jython related code? |
How official is that?
Does it cost any maintenance burden? If not, you have your answer :-) |
https://github.com/jythontools/jython
Yes, it currently not burdens for maintenance. But if not, can we gradually remove about alternative interpreter related code? Should we preserve the area for Jython? Okay, I understand that there must be a historical reason for those codes. But can we move a step for deprecating them? |
I think that everybody would like to see more working implementations of Python: That's why many tests are decorated with @support.cpython_only. That's also why the PEP-399 exists.
I'm not sure of which kind of changes do you have in mind. Ronan Lamy who works on PyPy recently contributed to CPython Lib/stat.py module to respect the PEP-399: bpo-38109. Such contribution is very welcomed :-) When PEPs are discussed, we also try to keep in mind that it should be possible to implement the change on other implementations. If it's not, it should be clearly mentioned and justified in the PEP. Examples: https://www.python.org/dev/peps/pep-0509/#changes "The choice of increasing or not the version when a dictionary method does not change its content is left to the Python implementation. A Python implementation can decide to not increase the version to avoid dictionary lookups in guards." https://www.python.org/dev/peps/pep-0445/ "The only implementation required to conform to this PEP is CPython, but other implementations may choose to be compatible, or to re-use a similar scheme." https://www.python.org/dev/peps/pep-0454/ "The tracemalloc module has been written for CPython. Other implementations of Python may not be able to provide it." |
I think such kind of questions should be asked on Python-Dev. Even the 2.7 stdlib and tests are not completely compatible with Jython. |
I definitely agree with it :)
I know some of the projects which implementing Python3.x interpreter with non-C languages. (e.g GraalPython, RustPython) And it will be good news to them. :) Thanks for the kind explanation about this sensitive issue. Is it okay to change the resolution of this issue to won't fix? |
Maybe most of the alternative interpreters will meet this issue. If the master branch code is Python 2.x, I didn't open this issue. But I think that I got the answer from Victor :) |
This issue is not really a concrete actionable issue. It sounds more like a general discussion about Python implementations. I agree with Serhiy that it should be moved to python-dev. And it would be nice to have such discussion on python-dev ;-) I close the issue. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: