GeezerVison is showing github.com — Remove `ByteString` from `typing` and `collections.abc` · Issue #118803 · python/cpython
Remove ByteString from typing and collections.abc #118803DescriptionFeature or enhancement
It was deprecated and scheduled for removal in 3.14
Original issue: #91896
Ref: 09b7695
Linked PRs
Reacted by Jelle Zijlstra Activityadded a commit that references this issue on May 8, 2024gh-118803: Remove `ByteString` from `typing` and `collections.abc` (#… cdce8p commented on May 26, 2025 Tbh I was a bit surprised that it didn't raise any DeprecationWarning on 3.13. Looking at #118804 it seems that was only emitted on isinstance checks. Most examples I've seen while testing 3.14 just import it at runtime to use as annotation.
It's a bit unfortunate to not have gotten a warning for it earlier as a few packages will now require immediate fixes for 3.14. Not sure if it would be worth it to revert the removal and add a proper DeprecationWarning on import (i.e. in typing.__getattr__)? Reacted by Joao S. O. Bueno Reacted by vivodi Reacted by vivodi JelleZijlstra commented on May 26, 2025 I'd be OK with that. This sort of removal can be pretty disruptive since libraries using it will usually be using a from import, so users who need those libraries will be completely unable to even import the library on 3.14.
What are some examples of libraries still using this? Reacted by vivodi Reacted by vivodi AlexWaygood commented on May 28, 2025 I'm also fine with doing a longer deprecation period here. The reason we didn't emit deprecation warnings when it was imported/accessed from typing.py initially was that it's included in typing.__all__, which means that from typing import * would have led to a deprecation warning being emitted. We realised that doing that is actually fairly common, and we couldn't remove it from __all__ because that itself was a breaking change.
Now that we've had deprecation warnings in the docs for 2 years, though (and some deprecation warnings at runtime), I think it would be fine to remove ByteString from typing.__all__, remove ByteString from collections.abc.__all__, and emit more aggressive deprecation warnings that trigger when you import it from typing or access it as an attribute from the module. It's still breaking (people will get NameErrors if they were relying on from typing import * to import ByteString for them), but it's much less breaking than what we have now, which is ByteString no longer existing at all. Reacted by vivodi Reacted by vivodi AlexWaygood commented on May 28, 2025
What are some examples of libraries still using this?
It was a while back (and they obviously no longer use it following my PR), but I was pretty concerned when aiohttp said that they hadn't seen any deprecation warnings about this in aio-libs/aiohttp#8408 (comment). I meant to propose extending the deprecation period, but lost track of it :-( Reacted by vivodi Reacted by vivodi cdce8p commented on May 28, 2025
What are some examples of libraries still using this?
I've only seen it a couple of times so far. Most cases have already been fixed for some time now:
Reacted by vivodi Reacted by vivodi JelleZijlstra commented on May 28, 2025 Anyone interested in sending a PR to restore it for 3.14? Reacted by vivodi Reacted by vivodi sobolevn commented on May 29, 2025 I think that we should check top 10000 packages for its usages. If there are many existing ones - it might be a good idea to restore it. But, if there are just several - then we should probably move forward, it was deprecated for 5 versions already, there was a lot of time to change the code .. deprecated-removed:: 3.9 3.14. It is not hard to fix in the library code as ByteString = bytes | bytearray. added 2 commits that reference this issue on Sep 18, 2025gh-118803: Make `ByteString` deprecations louder; remove `ByteString`… AlexWaygood commented on Sep 18, 2025 We've now done everything we plan to do here until 3.17 Reacted by Hugo van Kemenade
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|