Currently the documentation for the generic forms (e.g. what the parameters in square brackets mean) of standard collections (e.g. collections.abc.Generator), is still on the typing page (https://docs.python.org/3.10/library/typing.html#typing.Generator).

This is from before PEP 585 was implemented, which deprecated the ones in typing in favour of the aliases in collections.abc. The documentation for these should be moved, or at least linked to, in the collections.abc page. The same applies to builtin types like list which can now also be directly parameterised.

In the case of Generator, for example, the text at https://docs.python.org/3.10/library/typing.html#typing.Generator, "A generator can be annotated...", should be moved to 
https://docs.python.org/3.10/library/collections.abc.html#collections.abc.Generator.

I chose Generator as an example, because it has three parameters YieldType, SendType, ReturnType whose order I can't remember and need to look up. For some types, such as Iterable, the meaning of the parameter is quite straightforward, so little documentation is needed (so https://docs.python.org/3.10/library/typing.html#typing.Iterable just says "A generic form of https://docs.python.org/3.10/library/collections.abc.html#collections.abc.Iterable"), but there should still be a note on the collections.abc page that it can be parameterised.

Perhaps there should also be a message saying "new in version 3.9: this can now be parameterised" on each ABC collection.

I can see that it might not be desirable to have this information scattered across other pages, because it is fundamentally about typing and pretty unrelated to builtin documentation, so it may be preferable to just link to the typing page rather than move the text. But since the old generics are deprecated, if they are removed, the documentation must be preserved.

I think we should go ahead and duplicate the documentation in collections.abc (and in a few other places -- PEP 585 lists some builtins, some in contextlib, some in re). Then we won't have to worry about what happens when the typing module is slimmed down (presumably it will have to remain for things like Any, TypeVar, Generic).

Where are capabilities like "list[str]" and "dict[str, list[int]]" going to be documented?

> Where are capabilities like "list[str]" and "dict[str, list[int]]" going to be documented?

I think those should go with the individual types as well. AFter all, it's specific to the type how many parameters it has and what they mean. There should probably also be a general section explaining these generics, and the individual types can link to those so they don't have to repeat the same background information.

> I think those should go with the individual types as well

The list[] and dict[] stdtypes are in a different document from collections.abc.*. While this helps logical separation, I feel like it'd be tougher searching for type information compared to our current aggregate-everything-in-typing approach.

Where type hints for types should belong has been a hot subject for some time. This was discussed at the typing summit, and also by the docs WG.

- Docs WG: https://github.com/python/docs-community/issues/8
- Downstream typing possible tutorial: https://github.com/python/typing/issues/891
- Downstream typing's docs: https://github.com/python/typing/tree/master/docs

The general consensus it seems is to separate complex information from the CPython docs. I like this approach because type hints have zero meaning to CPython, so placing them in docs meant for runtime behavior feels strange.

OTOH, external docs won't be able to keep up with the subtleties of multiple different versions of typing in CPython. So *some* information should be kept in CPython docs.

I think for now, a link in collections.abc pointing to typing would suffice. In the future when Python 3.9 becomes an "old" version and PEP 585 notation is commonplace, we should copy them over like Guido suggested (and if Raymond is OK with collections.abc docs including that sort of information). Guido or Raymond may have other plans though ;-).

I'm not against additional tutorial for typing. But the standard library manual is supposed to be a complete reference. There is enough variation between different generic types (e.g. are the parameters covariant?) that ought to be documented. I don't want to create a "typing ghetto" where all typing information is collected as if it wasn't really part of the language.