Skip to content

Conversation

brianschubert
Copy link
Member

Refs mypyc/mypyc#838

This PR populates __text_signature__ for compiled functions, making runtime signature introspection possible (i.e. inspect.signature(func)).

While __text_signature__ is an undocumented CPython implementation detail, other extension module generators are using it in practice. For example, PyO3 and Cython both support it. I think it would be reasonable for mypyc to support it too.

Some function signatures can't be represented by __text_signature__ (namely, those with complex default arguments). In those cases, no signatures are generated (same as the current behavior).

Verified

This commit was signed with the committer’s verified signature.
brianschubert Brian Schubert

Verified

This commit was signed with the committer’s verified signature.
brianschubert Brian Schubert

Verified

This commit was signed with the committer’s verified signature.
brianschubert Brian Schubert

Verified

This commit was signed with the committer’s verified signature.
brianschubert Brian Schubert
See mypyc#1109
@brianschubert brianschubert added the topic-mypyc mypyc bugs label Jun 16, 2025

Verified

This commit was signed with the committer’s verified signature.
brianschubert Brian Schubert

Verified

This commit was signed with the committer’s verified signature.
brianschubert Brian Schubert
Copy link
Collaborator

@JukkaL JukkaL left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this is a very useful feature! I have one question about default values, but solving this is not necessary to merge this PR.

for op in block.ops:
if isinstance(op, Assign) and op.dest.name == name:
return _extract_python_literal(op.src)
return _NOT_REPRESENTABLE
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have any ideas about how to generalize this to support more kinds of default values? I guess we could special case empty lists and dictionaries, which are somewhat common (even if you are not supposed to use them as defaults), and perhaps named constants and enum values. What about using a placeholder default value for unsupported default values, such as ... (ellipsis)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other defaults are loaded with LoadStatic ops, so we'd need to look at the module's __top_level__ IR to extract the values. That isn't too tricky to do (in fact I already have a rough patch that does that), but it could be expensive performance wise, since __top_level__ can be quite big and we'd be doing potentially many linear searches. Alternatively, we could try recording information about default arguments earlier on during IR building, though I haven't figured out a simple way to do that yet

What about using a placeholder default value for unsupported default values, such as ... (ellipsis)?

I actually tried that in a previous revision :-) I was worried that it might conflict with using an actual Ellipsis default argument at runtime. I'm also not sure what effect using a placeholder might have on the tools that consume these signatures. For example, I think stubtest might complain if a runtime signature had ... as a default argument when the parameter isn't typed to actually accept EllipsisType

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recording information about default argument values during IR building seems like the most promising approach to me, though I'm not sure how easy this would be to implement. They could perhaps be stored in FuncDecl or FuncSignature. I agree with you that analyzing __top_level__ seems too inefficient (and also inelegant).

Verified

This commit was signed with the committer’s verified signature.
brianschubert Brian Schubert

Verified

This commit was signed with the committer’s verified signature.
brianschubert Brian Schubert
Copy link
Collaborator

@JukkaL JukkaL left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine as an initial implementation. We can figure out more complex cases later.

@JukkaL JukkaL merged commit 526fec3 into python:master Jul 7, 2025
14 checks passed
@JukkaL
Copy link
Collaborator

JukkaL commented Jul 7, 2025

@brianschubert Can you create a follow-up mypyc issue about the remaining cases, with some discussion based on the comments in this PR?

@jorenham
Copy link
Contributor

jorenham commented Aug 25, 2025

I believe that this change is why I'm seeing a bunch of new errors pop up when running stubtest on scipy-stubs using mypy master (ffe2db8).

All errors are seem to be related to __cinit__ Cython methods:

Each parameter is reported as a separate error, and aliases are counted double, which causes 75 errors to be reported here.

I must admit that I know very little about cython and the C-side of cpython, so I'm not able to see why this is happening. But the fact that these only occur in case of these __cinit__ methods is kinda sus afaik. However, there's of course also a chance that I'm doing something wrong in scipy-stubs. But otherwise, if this is indeed a bugger, then I wouldn't mind opening an issue for this :)

Oh and here are the errors: https://gist.github.com/jorenham/3d41e79607bcc1f45267acc1566833d2


update:

This might also be relevant infomation:

>>> from scipy.stats._unuran.unuran_wrapper import TransformedDensityRejection
>>> TransformedDensityRejection.__init__.__text_signature__
'($self, /, *args, **kwargs)'

So it's kinda odd that stubtest says it's def (self) at runtime, right?

@brianschubert
Copy link
Member Author

brianschubert commented Aug 25, 2025

@jorenham More likely you're seeing an effect of #18259. This change only affects extension modules that are generated with mypyc, not Cython. #18259 made stubtest sensitive to signature information on C extension classes, which equally affects hand-written C extension modules and mypyc or Cython generated extension modules.

@brianschubert
Copy link
Member Author

brianschubert commented Aug 25, 2025

Hmm, your issue seems to be due to stubtest looking at TransformedDensityRejection.__init__.__objclass__ for signature information, which it expects to be TransformedDensityRejection, but is actually object at runtime:

>>> from scipy.stats._unuran.unuran_wrapper import TransformedDensityRejection
>>> TransformedDensityRejection.__init__.__objclass__
<class 'object'>

For comparison, this is what happens for stdlib C extension classes:

>>> import pickle
>>> pickle.Pickler.__init__.__objclass__
<class '_pickle.Pickler'>

and for mypyc native classes:

>>> import mypy.types
>>> mypy.types.Instance.__init__.__objclass__
<class 'mypy.types.Instance'>

So, it seems like there's either something funny with Cython extension classes, or a wrong assumption was made in #18259.

(new issue to track this would be welcome!)

@jorenham
Copy link
Contributor

(new issue to track this would be welcome!)

🫡 #19732

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-mypyc mypyc bugs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants