René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Discourage and deprecate `typing.AnyStr`","articleBody":"# Feature or enhancement\r\n\r\nWe should discourage and deprecate `typing.AnyStr`.\r\n\r\n# Pitch\r\n\r\n`typing.AnyStr` is bad for many reasons:\r\n\r\n1. The name implies that it has something to do with the type `Any`. It has nothing to do with the type `Any`.\r\n2. The name implies that it means \"any string\". It does not mean \"any string\".\r\n3. `AnyStr` is a `TypeVar`, but the name does not follow the common naming convention for TypeVars (using a \"T\" suffix). Many users appear to think that it is equivalent to `str | bytes`, which is incorrect.\r\n4. `AnyStr` is the only type variable that is publicly exported from the `typing` module. Unusually, it is a constrained type variable. Constrained type variables are usually not what users want for modern APIs. Bound type variables, in general, have more intuitive semantics than constrained type variables.\r\n5. One of the motivations for PEP-695 (accepted by the Steering Council, and now implemented) was the fact that reusable type variables can be confusing in terms of their scope. In general, I believe the consensus of the typing community is that using PEP-695 syntax for creating type variables clarifies the scope of type variables and makes them more intuitive for users. As such, we should discourage using reusable TypeVars such as `AnyStr`.\r\n\r\nFor all of these reasons, `AnyStr` is _very_ commonly misused, especially by typing beginners. We get many PRs at typeshed that misuse `AnyStr`, and it can often be hard to catch these misuses in CI (careful manual review is required).\r\n\r\nTherefore, we should discourage and deprecate `typing.AnyStr`. Unfortunately, it is very widely used, so the deprecation period will have to be a long one.\r\n\r\nI propose the following plan:\r\n\r\n1. Clarify the docs for `typing.AnyStr`. Explain more clearly the differences between `AnyStr` and a union; give examples of uses of `AnyStr` that would be invalid. This docs clarification can be backported to 3.12 and 3.11.\r\n2. In Python 3.13, state in the docs that using `AnyStr` is deprecated and that users are encouraged to use PEP-695 syntax wherever possible.\r\n3. In Python 3.16, remove `AnyStr` from `typing.__all__`, and start emitting a `DeprecationWarning` if a user does `from typing import AnyStr` or accesses `typing.AnyStr`.\r\n\r\n   Removing it from `__all__` will be a breaking change, but it's the only way to emit a `DeprecationWarning` for `typing.AnyStr` before removing it unless we're okay with emitting a `DeprecationWarning` any time a user does `from typing import *` (and I'm not).\r\n4. In Python 3.18, remove `AnyStr` from the `typing` module.\r\n\r\nThoughts?\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-107045\n* gh-107116\n* gh-107503\n* gh-107504\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/AlexWaygood","@type":"Person","name":"AlexWaygood"},"datePublished":"2023-06-09T16:00:42.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":14},"url":"https://github.com/105578/cpython/issues/105578"}