> That's likely true for CPython itself, at least currently.
> I don't think it's generally a safe assumption in the CPython
> ecosystem, which includes things like Cython, Numba, Nuitka and others,

While I'm happy to accommodate these other projects if it's easy to do
so, my primary concern is what's best for CPython.


> Reducing it to a string representation, especially now that we
> have annotations for Python signatures, sounds like a major step
> backwards.

What nonsense.  CPython has never had signature information for
builtins before.  And, the format of __text_signature__ allows
expressing a signature that uses every feature available in
inspect.Signature.  This cannot legitimately be called a "major step
backwards".

Also, PEP 8 forbids using annotations in the CPython library, which
includes all of CPython's builtins.  So using annotations in any way
for this was off the table.


> Safer ways to do it would be extending the type, or adding a flag
> in some way, but that's going to a) hurt more than the current
> situation, and b) become wasteful at some point when the
> __text_signature__ actually gets replaced by a proper function
> interface for CPython builtins. The fact that that wasn't doable
> for Py3.4 any more doesn't mean it shouldn't be done at all.

You imply that __text_signature__ is improper and unsafe.  We debated
how to communicate static signature information from C to Python at
runtime, and this was easily the best--most expressive, most
compact.  So it is entirely proper.  Hiding it in the docstring was
a cheap hack, I'll admit, but with an appropriately unlikely signature
('sig=') it seems perfectly safe.

If in the future we need to change how we represent signatures, we can
remove it.  It's an undocumented internal implementation detail and we
have free license to do so.  So even if we changed our mind in the
future I don't see how it would be "wasteful".