# "Wrong" Special Form

**URL:** <https://discuss.python.org/t/wrong-special-form/103832>\
**Category:** Ideas\
**Tags:** typing\
**Created:** [September 19, 2025, 7:28am UTC](https://discuss.python.org/t/wrong-special-form/103832 "2025-09-19T07:28:14Z")\
**Posts on this page:** 1\
**Showing post:** 28

<div class="post-metadata">

**Author:** ![Daverball](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/daverball/32/15931_2.png) [@Daverball](https://discuss.python.org/u/Daverball)\
**Post date:** [November 11, 2025, 8:44am UTC](https://discuss.python.org/t/wrong-special-form/103832/28 "2025-11-11T08:44:37Z")

</div>

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\].

* * *

1. It gives the additional benefit/flexibility of being able to specify what return type is used for that function 

2. in which case the objections for `TypeError` would be valid, at which point my preference would probably shift towards `TypeViolation` or `Violation` 

3. 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

---

_[View the full topic](https://discuss.python.org/t/wrong-special-form/103832)._