You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Remove ByteString from typing and collections.abc #118803
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__)?
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?
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.
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 :-(
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:
crc -> Fixed in 5.0 (Nicoretti/crc@2ae4871). For Home Assistant we have a dependency which still (unnecessarily) pins the version to <5. Will work to update that instead.
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.
Activity
pythongh-118803: Remove `ByteString` from `typing` and `collections.abc`
gh-118803: Remove `ByteString` from `typing` and `collections.abc` (#…
cdce8p commentedon 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
isinstancechecks. 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__)?JelleZijlstra commentedon 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
fromimport, 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?
AlexWaygood commentedon 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.pyinitially was that it's included intyping.__all__, which means thatfrom 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
ByteStringfromtyping.__all__, removeByteStringfromcollections.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 getNameErrors if they were relying onfrom typing import *to importByteStringfor them), but it's much less breaking than what we have now, which isByteStringno longer existing at all.AlexWaygood commentedon May 28, 2025
It was a while back (and they obviously no longer use it following my PR), but I was pretty concerned when
aiohttpsaid 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 :-(cdce8p commentedon May 28, 2025
I've only seen it a couple of times so far. Most cases have already been fixed for some time now:
crc-> Fixed in5.0(Nicoretti/crc@2ae4871). For Home Assistant we have a dependency which still (unnecessarily) pins the version to<5. Will work to update that instead.pynacl-> Fixed last year in Fix compatibility with Python 3.14.0a1 pyca/pynacl#848 but no new release yet.JelleZijlstra commentedon May 28, 2025
Anyone interested in sending a PR to restore it for 3.14?
sobolevn commentedon 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 asByteString = bytes | bytearray.18 remaining items
Revert "gh-118803: Remove `ByteString` from `typing` and `collections…
Revert "pythongh-118803: Remove `ByteString` from `typing` and `colle…
[3.14] Revert "gh-118803: Remove `ByteString` from `typing` and `coll…
pythongh-118803: Improve documentation around `ByteString` deprecation
pythongh-118803: Make `ByteString` deprecations louder; remove `ByteS…
gh-118803: Improve documentation around `ByteString` deprecation (#13…
pythongh-118803: Improve documentation around `ByteString` deprecation (
[3.14] gh-118803: Improve documentation around `ByteString` deprecati…
[3.13] gh-118803: Improve documentation around `ByteString` deprecati…
gh-118803: Make `ByteString` deprecations louder; remove `ByteString`…
AlexWaygood commentedon Sep 18, 2025
We've now done everything we plan to do here until 3.17
[3.13] gh-118803: Fixup a few references in the 3.13 branch to the in…