Revert "gh-118803: Remove ByteString from typing and collections.abc (#118804)"
#138990
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a more-or-less clean revert of commit 2f4db5a. The PR adds back
collections.abc.ByteStringandtyping.ByteString, postponing their removals to Python 3.17.Prior to 2f4db5a, we had deprecation warnings for
ByteString, but they only triggered if you subclassedByteStringor usedByteStringas the second argument toisinstance()orissubclass(). Since the removal ofByteString, we've had multiple reports from users that these deprecation warnings have been insufficient and that the removal ofByteStringtook them by surprise:ByteStringfromtypingandcollections.abc#118804 (comment)typing.ByteStringaio-libs/aiohttp#8408 (comment)ByteStringfromtypingandcollections.abc#118803 (comment)That's because many uses of
ByteStringdo not subclassByteStringor use it as the second argument toisinstance(). Many uses ofByteStringsimply use it as a type annotation, and simply using it as a type annotation would not be sufficient to trigger a runtime deprecation warning informing you that the object would be removed in Python 3.14. Prior to removing the object from thecollections.abcandtypingmodules entirely, it would be much better if we emitted aDeprecationWarningwhenever the object is accessed or imported fromcollections.abc/typing.Now, there's a good reason why we didn't do that in Python 3.12:
ByteStringis present both incollections.abc.__all__andtyping.__all__. Naively emitting a deprecation warning every time it was imported or accessed would have caused deprecation warnings to be emitted on everyfrom collections.abc import *orfrom typing import *statement, which was deemed at the time to be far too noisy and disruptive (#104424). One solution would have been to removeByteStringfromcollections.abc.__all__andtyping.__all__, but we couldn't do that right away in Python 3.12 as it was a breaking change.Nonetheless, removing
ByteStringfromcollections.abc.__all__andtyping.__all__is much less of a breaking change than removing it entirely without prominent runtime deprecation warnings. Now that we're in a place where it's been deprecated in the docs for 2 releases and had some runtime deprecation warnings for 2 releases, I think we're now in a position where we can:ByteStringfromcollections.abc.__all__andtyping.__all__in Python 3.15This PR should strictly improve backwards compatibility. It will not break anything for users who have already removed their uses of
ByteString; they will simply be extremely well prepared for whenByteStringis removed for good in Python 3.17. For users who have been unaware of the deprecation up till now, however (and there may be many such users that we don't know about in closed-source projects), this will mean that they are given much better notice that they should adapt their code for the forthcoming removal ofByteStringin Python 3.17.ByteStringfromtypingandcollections.abc#118803📚 Documentation preview 📚: https://cpython-previews--138990.org.readthedocs.build/