Reproduction:

```
from graphlib import TopologicalSorter

TopologicalSorter[str]({"a": {}, "b": {"a"}})
```
```
$ mypy /tmp/toposort.py
Success: no issues found in 1 source file
$ python3 /tmp/toposort.py
Traceback (most recent call last):
  File "/tmp/toposort.py", line 3, in <module>
    TopologicalSorter[str]({"a": {}, "b": {"a"}})
TypeError: 'type' object is not subscriptable
```

I opened the issue here (rather than typeshed) because we'd presumably like to support this at runtime too.

Typeshed link: https://github.com/python/mypy/blob/0a830481980bfc554ded61a3eaaaecde384a21e4/mypy/typeshed/stdlib/graphlib.pyi#L6

New changeset 3cb9731b7e59b0df9a7a9ab6b7746a669958b693 by Jacob Hayes in branch 'main':
bpo-45359: Support TopologicalSorter type subscript (GH-28714)
https://github.com/python/cpython/commit/3cb9731b7e59b0df9a7a9ab6b7746a669958b693

The new feature is applied to Python 3.11 only

Thanks for merging!

Should typeshed be updated for <3.11 in the meantime or do you suggest `if TYPE_CHECKING` blocks on user side? Perhaps it's a non-issue if no one else has noticed this. :)

`if TYPE_CHECKING:` is a good choice, it works fine just now.
`from __future__ import annotations` is another alternative.

I don't see a reason for REMOVING already existing and correct annotations from typeshed.

Another option for code using Python <3.11, that will work without the `from __future__ import annotations` import, is to do something like this:

```
from graphlib import TopologicalSorter
x: 'TopologicalSorter[str]' = TopologicalSorter({"a": {}, "b": {"a"}})
```

By using a string as the annotation, we give mypy the specificity it needs, but the expression will never need to be resolved at runtime.

Thanks for the tips! I've been using this patch in my own code in a early imported `__init__.py`:

```
from graphlib import TopologicalSorter
from types import GenericAlias

if not hasattr(TopologicalSorter, "__class_getitem__"):  # pragma: no cover
    TopologicalSorter.__class_getitem__ = classmethod(GenericAlias)  # type: ignore
```

Certainly a bit hacky, but aside from no-op on >=3.11 and satisfying mypy, it supports runtime type inspection via `get_type_hints` before 3.11 (which otherwise still errors for stringized versions). The stringized versions are probably a bit simpler/safer for most folks though :)