I can read some of Jython related code on the master branch.
ASFIK, this codes are the legacy of Jython2.
Currently, Jython3 stops development since 2017.
https://github.com/jython/jython3

Can we get rid of the Jython related code?
Or is there any reason to maintain those codes?

> Currently, Jython3 stops development since 2017.

How official is that?

> Or is there any reason to maintain those codes?

Does it cost any maintenance burden? If not, you have your answer :-)

> How official is that?

https://github.com/jythontools/jython
jeff5 is now maintaining Jython2 but I can not find Jython3 under development.

> Does it cost any maintenance burden? If not, you have your answer :-)

Yes, it currently not burdens for maintenance.
But is the policy of CPython to care about alternative interpreter implementation? So if the new alternative implementation request to modify CPython code. Is it okay?
If so I agree with not to remove Jython code on Python3.x

But if not, can we gradually remove about alternative interpreter related code? Should we preserve the area for Jython?
https://github.com/python/cpython/blob/master/Doc/using/cmdline.rst#options-you-shouldnt-use

Okay, I understand that there must be a historical reason for those codes. But can we move a step for deprecating them?

> But is the policy of CPython to care about alternative interpreter implementation?

I think that everybody would like to see more working implementations of Python:
https://hub.packtpub.com/lukasz-langa-at-pylondinium19-if-python-stays-synonymous-with-cpython-for-too-long-well-be-in-big-trouble/

That's why many tests are decorated with @support.cpython_only.

That's also why the PEP 399 exists.


> So if the new alternative implementation request to modify CPython code. Is it okay? If so I agree with not to remove Jython code on Python3.x

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 think that everybody would like to see more working implementations of Python:

I definitely agree with it :)

> I'm not sure of which kind of changes do you have in mind.
> Such contribution is very welcomed :-)

I know some of the projects which implementing Python3.x interpreter with non-C languages. (e.g GraalPython, RustPython)
I just want to know there will be a chance to them if they meet the wall to implementing an interpreter due to their language-specific issue.

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?

> Even the 2.7 stdlib and tests are not completely compatible with Jython.

Maybe most of the alternative interpreters will meet this issue.
AFAIK, Dropbox pyston project also met same issue.
(https://blog.pyston.org/)

If the master branch code is Python 2.x, I didn't open this issue.
But I just want to know CPython is still willing to supporting interpreter specific APIs
(e.g is_jython)

But I think that I got the answer from Victor :)

> I think such kind of questions should be asked on Python-Dev.

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.