Remove `ByteString` from `typing` and `collections.abc`

[sobolevn]

Feature or enhancement

It was deprecated and scheduled for removal in 3.14

Original issue: #91896
Ref: 09b7695

Linked PRs

• gh-118803: Remove ByteString from typing and collections.abc #118804
• Revert "gh-118803: Remove ByteString from typing and collections.abc (#118804)" #138990
• [3.14] Revert "gh-118803: Remove ByteString from typing and collections.abc (GH-118804)" (GH-138990) #138995
• gh-118803: Improve documentation around ByteString deprecation #139115
• gh-118803: Make ByteString deprecations louder; remove ByteString from typing.__all__ and collections.abc.__all__ #139127
• [3.14] gh-118803: Improve documentation around ByteString deprecation (GH-139115) #139136
• [3.13] gh-118803: Improve documentation around ByteString deprecation (#139115) #139137

[cdce8p]

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__)?

[JelleZijlstra]

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?

[AlexWaygood]

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.

[AlexWaygood]

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 :-(

[cdce8p]

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.
• pynacl -> Fixed last year in Fix compatibility with Python 3.14.0a1 pyca/pynacl#848 but no new release yet.

[JelleZijlstra]

Anyone interested in sending a PR to restore it for 3.14?