# Signatures, a call to action

**URL:** <https://discuss.python.org/t/signatures-a-call-to-action/23580>\
**Category:** Core Development\
**Created:** [February 6, 2023, 3:23am UTC](https://discuss.python.org/t/signatures-a-call-to-action/23580 "2023-02-06T03:23:34Z")\
**Posts on this page:** 1\
**Showing post:** 37

<div class="post-metadata">

**Author:** ![skirpichev](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/skirpichev/32/10996_2.png) [@skirpichev](https://discuss.python.org/u/skirpichev)\
**Post date:** [February 4, 2024, 6:48am UTC](https://discuss.python.org/t/signatures-a-call-to-action/23580/37 "2024-02-04T06:48:02Z")

</div>

> [@storchaka](#):
>
> It turns out that the difference in two implementations (list of signatures or the MultiSignature class) is small and does not matter much in comparison with other needed changes.

I’m thinking (as an outcome of [this thread](https://discuss.python.org/t/43914)) about the PEP that will expose the ` __text_signature__ ` (which is undocumented and private so far) string attribute for extension modules. With some minor additions for its format specification (return annotations so far).

Maybe we could hit two rabbits in one shot and include basic support for multiple signatures?

The proposed extension of the ` __text_signature__ ` (perhaps, renamed in this case as ` __text_signatures__ `) format is trivial: lets just list all different signatures one by one, separated by a newline. Each signature has a parameter list, enclosed by round brackets, optionally followed by ‘-\>’ and an expression (for return annotation). For example, in the `log()` case this will look like:

```python
($module, x, /)
($module, x, base, /)

```

The attribute will be created from the docstring just as we do it now (modulo renaming). Later we could modify the AC to support generation of the docstring from the clinic input, [proposed above](https://discuss.python.org/t/signatures-a-call-to-action/23580/19) by Raymond, add the `inspect.signatures()`, etc.

Fancy syntax using square brackets for optional arguments might look more economical. But I suspect its more suitable for typeless languages. Also, above proposal is almost compatible with Python syntax: every valid text signature, after simple tweaks, will be `ast.parse()`-able.

---

_[View the full topic](https://discuss.python.org/t/signatures-a-call-to-action/23580)._