# Expanded typing spec chapter for callables

**URL:** <https://discuss.python.org/t/expanded-typing-spec-chapter-for-callables/51486>\
**Category:** Typing\
**Tags:** typing-spec\
**Created:** [April 20, 2024, 10:24pm UTC](https://discuss.python.org/t/expanded-typing-spec-chapter-for-callables/51486 "2024-04-20T22:24:50Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![hauntsaninja](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hauntsaninja/32/12451_2.png) [@hauntsaninja](https://discuss.python.org/u/hauntsaninja)\
**Post date:** [April 23, 2024, 6:18pm UTC](https://discuss.python.org/t/expanded-typing-spec-chapter-for-callables/51486/3 "2024-04-23T18:18:43Z")

</div>

mypy’s current behaviour is a special case, but it’s in response to one of the most popular mypy issues of all time. I don’t know that I’d be willing to remove it entirely. I don’t know if this feels any better to you, but for what it’s worth I would be willing to e.g. remove the `(x: int, *args: Any, **kwargs: Any)` → `Concatenate[int, ...]` bit, and only keep the core `(*args: Any,**kwargs: Any)` → `...` bit. Like Guido said on that mypy issue, this might be a case where practicality beats purity.

`(*args: ..., **kwargs: ...)` is an interesting suggestion. It would still be a breaking change for mypy users and it suggests a different semantics to me (maybe something like [this thread](https://discuss.python.org/t/extends-copy-signature-to-add-arguments-to-an-overriden-method-of-a-derived-class/51333)), but I’m curious to hear what other folks think.

---

_[View the full topic](https://discuss.python.org/t/expanded-typing-spec-chapter-for-callables/51486)._