On 2/4/21 11:33 PM, Stefan van der Walt wrote:
Hi David,
Thank you for writing up the PEP; that was an interesting read.
On Thu, Feb 4, 2021, at 22:27, David Foster wrote:
PEP 484 [^type-c] defines the type `Type[C]` where `C` is a class, to refer to a class object that is a subtype of `C`. It explicitly does not allow `Type[C]` to refer to typing special forms such as the runtime object `Optional[str]` even if `C` is an unbounded `TypeVar`. This PEP proposes a new type `TypeForm` that allows referring to both any class object and *also* to any runtime object that is a typing special form, such as `Optional[str]`, `Union[int, str]`, or `MyTypedDict`.
The question raised on the GitHub issue [0], "Why can't we make `Type[T]` also work for other special forms?", will likely come up for others reading this too. Would it be worth adding a sentence to explain?
Agreed. I'll plan to put a mention in the Rejected Ideas section, since extending Type[T] was also my first reaction when encountering the non-expressability problem that this PEP is aiming to solve.
[...] Phrased differently: why can the `trycast` definition not be:
``` def trycast(form: Type[T], value: object) -> Optional[T]: ... ```
That seems to work OK (see attached), although understanding why it isn't adequate would help motivate the document.
Good point. The above definition works if you pass in regular class types (like `int` or `str`) but rejects more complex arguments like `Union[int, str]`. And that is probably not obvious.
I don't know who the target audience of the PEP is, but presumably it would not hurt to make it a bit more widely accessible.
I'd say the target audience would be users of Python's static typing annotations, particularly relatively advanced users who were looking at implementing "new kinds of metaprogramming functions that operate on typing special forms". (Quote is from the first sentence in the PEP's "Motivation" section.) So far the main likely users of TypeForm seem to be libraries that manipulate abstract structures whose shape is defined by a type annotation. For example the pydantic and trycast libraries.
Crystallizing the advantage over what is currently available with usage examples of, say, `Union[int, str]`, would help.
I did make an example with `deunionize` which wouldn't be expressable at all with Type[C], although perhaps that's not immediately obvious. I will grant my only *early* example I had used `Shape` (a TypedDict), which I believe would still have worked with a Type[C].
I've never been active on a SIG before, so please accept my apologies if comments from those still learning the inner workings of types are considered unhelpful at this stage or a breach of social protocol.
I'm personally open to well-considered feedback from all, even with occasional mistakes and misunderstandings. 👍 It's worth considering that any particular expert is typically only an expert in a few areas in any case. For example a lot of the recent detailed technical discussion on the sister Variadic Generics thread is now a bit over my head. ^_^; -- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy