Description

sobolevn

opened on Nov 14, 2022

Issue body actions

Hi! I am CPython contributor :)
And I've recently noticed that for the last 22 years we have some special casing for org.python.core.PyStringMap.

Here are they:

• https://github.com/python/cpython/blame/db115682bd639a2642c617f0b7d5b30cd7d7f472/Lib/copy.py#L59-L62
• https://github.com/python/cpython/blame/db115682bd639a2642c617f0b7d5b30cd7d7f472/Lib/pickle.py#L101-L105
• https://github.com/python/cpython/blame/db115682bd639a2642c617f0b7d5b30cd7d7f472/Lib/xml/sax/__init__.py#L98-L100

The question is: do we still need it?

Some concerns:

1. It imports code from some third-party module in the stdlib. This is the only place (there might be some other cases that I am not familiar with, please proove me wrong) where we do it. It might be a source of some unexpected results if user has the same package structure. It might be even related to security, because importing third-party modules is never safe in Python
2. Jython seems to only support 2.7 a the moment, so we might not need this anymore in our core library 🤔

Please, share your vision on this 🙂

Activity

1. jeff5 commented on Nov 14, 2022

   

   jeff5

   on Nov 14, 2022

   Member

   More actions

   tl;dr: It's fine to remove from 3.x; I assume you have no interest in doing so from 2.7.

   Jython copies the CPython stdlib, and shadows parts of it with modified versions. This is a pain to maintain so it was always the ambition to have one stdlib that worked with both. We mostly haven't managed to back port changes.

   You'll find the occasional concession to Jython in CPython source and we always appreciate it when discussion of Python the language is distinguished from CPython the implementation.

   As we only have a viable 2.7 at present, we only use the 2.7.x stdlib, and I assume you have no interest in changing it there.

   We hope to support Python 3 eventually, so would appreciate the possibility of a common stdlib. The detail of any support already in 2.7 has a slim chance of being relevant to a Jython 3. (This one at less than evens.)

   The best thing you can do for other implementation is not to include (in tests mainly) behaviours that are CPython implementation details, or not without a skip-guard, anyway.
2. sobolevn commented on Nov 14, 2022

   

   sobolevn

   on Nov 14, 2022

   Author

   More actions

   @jeff5 thanks a lot for your answer! Yes, my main goal is to remove these details from CPython3.12+

   Older versions will not be changed.

   We also care about other implementations and support @cpython_only set of tests for the implementation details. Right we have reports from PyPy mostly.

   Please, take a look at the proposed changes if you have the time: python/cpython#99484

   I am going to close this issue :)
3. sobolevn

   closed this as completedon Nov 14, 2022

Issue actions