Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

gh-101552: Allow pydoc to display signatures in source format#124669

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
JelleZijlstra merged 13 commits intopython:mainfromJelleZijlstra:sigdocs
Oct 9, 2024

Conversation

@JelleZijlstra
Copy link
Member

@JelleZijlstraJelleZijlstra commentedSep 27, 2024
edited
Loading

  • Add aannotations_format argument toinspect.signature, matchingannotationlib.Format
  • Add anunquote_annotations argument toinspect.Signature.format, allowing string annotations to be displayed without quotes
  • Use the new functionality in pydoc to display signatures in source format.

📚 Documentation preview 📚:https://cpython-previews--124669.org.readthedocs.build/

ida=inspect_deferred_annotations
sig=inspect.Signature
par=inspect.Parameter
PORK=inspect.Parameter.POSITIONAL_OR_KEYWORD
Copy link
Member

Choose a reason for hiding this comment

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

🐷

AlexWaygood and efimov-mikhail reacted with heart emoji
Copy link
Member

@AlexWaygoodAlexWaygood left a comment

Choose a reason for hiding this comment

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

Nice! Some nitpicks, but nothing blocking really

:func:`copy.replace`.

..method::format(*, max_width=None)
..method::format(*, max_width=None, unquote_annotations=False)
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't feel like a totally correct use of "unquote" to me... Maybe the parameter could be calledremove_annotation_quotes instead ofunquote_annotation...? I think that might also reflect slightly better the fact that not all annotations will necessarily be quoted at all.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

We use "unquote" in various other places (e.g.,https://docs.python.org/3.13/library/csv.html#csv.QUOTE_NOTNULL); I feel it's more clear and concise

Copy link
Member

Choose a reason for hiding this comment

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

"unquoted" is used inhttps://docs.python.org/3.13/library/csv.html#csv.QUOTE_NOTNULL as an adjective rather than a verb. I think it makes sense to talk about something being "unquoted" but less sense to talk about "unquoting" something.

Copy link
Contributor

Choose a reason for hiding this comment

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

"dequote"?

Copy link
Contributor

Choose a reason for hiding this comment

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

If I'm reading the code correctly, if this is false (the default) we userepr on annotation values that are strings, and if it's true we skiprepr only for strings. So this is a passive operation--if the value is true, wedon't do something, and when it's false wedo do something. I think that's why this is awkward.

I suggest the clearest way to express this is to flip it. Negate the boolean and rename itquote_annotations=True. If it's true (the default) we quote annotations, and if it's false we don't. I might even go with the wordierquote_annotation_strings=True, as we're only allowing the user to control quoting or not-quoting the annotations when they're strings. But I don't have a strong opinion about that.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Good idea, changing that.

Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
attempt to automatically un-stringize the annotations using
:func:`annotationlib.get_annotations`. The
*globals*, *locals*, and *eval_str* parameters are passed
*globals*, *locals*,*eval_str*,and *annotation_format* parameters are passed
Copy link
Contributor

Choose a reason for hiding this comment

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

It's a minor thing, but:globals,locals, andeval_str are passed in to parameters with the same name when callingget_annotations. Butannotation_format is passed in to a parameter with a different name (justformat). It might be nice to explicitly tell that to the user.

I realize the documentation doesn't explicitly detail where these parameters go, so this would be all-new text. And when I try it in my head it always comes across as clumsy. So... should we even bother to try? Would anybody be confused if we didn't bother to explain it?

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Good point, I will add a separate sentence about theannotation_format parameter.

:func:`copy.replace`.

..method::format(*, max_width=None)
..method::format(*, max_width=None, unquote_annotations=False)
Copy link
Contributor

Choose a reason for hiding this comment

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

If I'm reading the code correctly, if this is false (the default) we userepr on annotation values that are strings, and if it's true we skiprepr only for strings. So this is a passive operation--if the value is true, wedon't do something, and when it's false wedo do something. I think that's why this is awkward.

I suggest the clearest way to express this is to flip it. Negate the boolean and rename itquote_annotations=True. If it's true (the default) we quote annotations, and if it's false we don't. I might even go with the wordierquote_annotation_strings=True, as we're only allowing the user to control quoting or not-quoting the annotations when they're strings. But I don't have a strong opinion about that.

@JelleZijlstraJelleZijlstraenabled auto-merge (squash)October 9, 2024 04:39
@JelleZijlstraJelleZijlstra merged commit7840638 intopython:mainOct 9, 2024
34 checks passed
efimov-mikhail pushed a commit to efimov-mikhail/cpython that referenced this pull requestOct 9, 2024
qtprojectorg pushed a commit to pyside/pyside-setup that referenced this pull requestMay 23, 2025
Python 3.14 changed formatannotation() function signature by adding `*,quote_annotation_strings=True` at the end of it.Since we only care about avoiding `text.removeprefix('typing.')`, let'sjust pass extra args/kwargs as is to keep compatibility with < 3.14.[1]python/cpython#124669Change-Id: Ic115ed5cc8766cdf60286e88f6cfa79e263f64c9Reviewed-by: Łukasz Patron <priv.luk@gmail.com>Reviewed-by: Christian Tismer <tismer@stackless.com>Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@larryhastingslarryhastingslarryhastings left review comments

@AlexWaygoodAlexWaygoodAlexWaygood approved these changes

@carljmcarljmcarljm approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@JelleZijlstra@carljm@larryhastings@AlexWaygood

[8]ページ先頭

©2009-2025 Movatter.jp