I still don’t really like any of the suggested names. I would personally prefer the decorator approach with @type_error, the way this feature has previously been suggested[1]. I think there’s also a potential missed opportunity for generalizing this feature along with @deprecated into something more widely useful like typing.dataclass_transform for defining custom decorators that emit some category of user-facing warning or error. Since it’s quite common for libraries to define something like that. It would also open up the possibility for user-defined type error categories that can be ignored in a more granular fashion, like giving libraries the opportunity to have some pedantic errors that are off by default, but can be enabled by changing the type checker configuration, similar to how deprecated errors are off by default in mypy.
That being said, having a special form in addition to a decorator could potentially be useful[2], the same goes for @deprecated, since right now you need something like @property to make deprecated attributes work. On the other hand, you can only easily get the benefit of a runtime warning with a decorator, so maybe restricting this feature to decorators is fine, even if it’s less ergonomic[3].
It gives the additional benefit/flexibility of being able to specify what return type is used for that function ↩︎
in which case the objections for
TypeErrorwould be valid, at which point my preference would probably shift towardsTypeViolationorViolation↩︎Although it might be interesting to think about a class level decorator which accepts a mapping for deprecated attributes, which inserts a hook into
__getattribute__for those attributes ↩︎