Repository navigation
CPython3.12a1 still has special case support for PyStringMap #217
Description
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:
- 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
- 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
jeff5 commentedon Nov 14, 2022
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.
sobolevn commentedon Nov 14, 2022
@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_onlyset 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 :)