# TypeForm: Spelling for a type annotation object at runtime **URL:** \ **Category:** Typing\ **Created:** [April 20, 2024, 2:56am UTC](https://discuss.python.org/t/typeform-spelling-for-a-type-annotation-object-at-runtime/51435 "2024-04-20T02:56:36Z")\ **Posts on this page:** 1\ **Showing post:** 19
**Author:** ![mikeshardmind](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikeshardmind/32/14381_2.png) [@mikeshardmind](https://discuss.python.org/u/mikeshardmind)\ **Post date:** [May 13, 2024, 12:27am UTC](https://discuss.python.org/t/typeform-spelling-for-a-type-annotation-object-at-runtime/51435/19 "2024-05-13T00:27:36Z")
> [@davidfstr](#): > > `TypeForm[Generic[GenericArgs]]` isn’t valid syntax because `Generic[...]` isn’t a [type expression](https://typing.readthedocs.io/en/latest/spec/annotations.html#type-and-annotation-expressions) (or an annotation expression for that matter). Generic there wasn’t meant to be typing.Generic, just some Generic form which was valid within type form, I could have used a more careful term, but I thought the context would have made it obvious that I was not specifically speaking about typing.Generic, and only about something which had generic parameterization as a type form. > [@davidfstr](#): > > FWIW, the proposed handling of TypeForm in combination with `Annotated[...]` [is already defined to work that way](https://docs.google.com/document/d/1PRvl3uKE-BxvmyFO3Ic4fZDpgW2fOU58aYh3LJ3zLpk/edit#heading=h.xjol0b50dlex), stripping out the metadata component: I can work up an example later, but this doesn’t cover all of the same cases which runtime users were currently (mis)using `type` for, and which those uses were told to wait for type form, partially because of… > [@davidfstr](#): > > RE “typevariables can’t be bound to parameterized generics” I’d have to see an example to understand what you mean. And how is this limitation on type variables related to TypeForm? The extra level of nesting introduced for these cases to be “valid” changes where the parameterization would need to exist and be supported in cases that were ruled in [Is `Annotated` compatible with `type[T]`?](https://discuss.python.org/t/is-annotated-compatible-with-type-t/43898) as “misuse, and needing to wait on typeform” > [@MegaIng](#): > > (The point against adding syntax for HKTs I somewhat understand. However, I am personally just in favor of adding HKTs 🙃) I’m also in favor of adding HKTs, What I’ve said shouldn’t be read as not to add HKTs, but that if we don’t have them in full, we can still scope a set of rules here that allows a very narrow use that retains something users had a use case for, and arguably had those cases working in their type checkers already. --- _[View the full topic](https://discuss.python.org/t/typeform-spelling-for-a-type-annotation-object-at-runtime/51435)._