Does PEP 387 apply when correcting deviations from PEP 399?
Closed this issue · 5 comments
Modules (like datetime and zoneinfo) that have both pure Python and C-accelerated versions are subject to PEP 399 which says specifically that both the Python and C modules must pass the test suite — though the spirit of the PEP is that the modules should be drop-in replacements for each other with regards to any intentionally-public behavior.
We occasionally find that there is an unintentional discrepancy in behavior between the pure Python and C modules, and we would like to correct it — usually by making the Python version do what the C version does. A recent example of this is when it was discovered that datetime.timezone can be subclassed in the Python module, but not the C module. We decided to remove this capability from the Python module, and the question is: do we need a PEP 387 deprecation period in the pure Python version before we do so, even though we're just bringing it into alignment wth what the C module already does?
My 2 cents personal take: The C implementation is the one that builds of CPython use by default, correct? In that case, I do not think a PEP 387 deprecation period applies to a change of the pure Python implementation to bring its behavior into alignment. The pure Python code that people do not have an easy ability to use is having its behavior aligned with the actual C implementation that is what most of the world uses.
Technical details of this specific case: Lib/datetime.py imports the _datetime C extension, and falls back to Lib/_pydatetime.py if the C extension leads to an ImportError. So both versions of code are shipped, but one should basically never be public in any normal build.
We'll discuss and get back to you with an official answer.
My 2 cents personal take: The C implementation is the one that builds of CPython use by default, correct?
Yes, this is the case, but the one wrinkle is that PyPy uses the pure Python version unconditionally (since for them, that's the faster version), so there are people out there using the pure Python module without doing any kind of funky thing that would disable the C version. The same goes for zoneinfo and I imagine also heapq.
Yep. Though how much code exclusively uses only that version? I doubt it is a lot, or at least code that is is presumably more likely in private-code land than OSS or anything on PyPI where PyPy is the only runtime someone runs the code on. I think it is fair to say that's up to PyPy to decide themselves when they bring in the 3.13 stdlib.
FWIW, PyPy's official policy is that undocumented divergence from CPython is a bug to be fixed, and will apply the changes with no deprecation warning for already released versions of Python.
The steering council discussed this today and agree with my response above. no need for a deprecation period.