Skip to content

Keep inline annotations over docstring generated ones #61

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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Jul 17, 2025

Conversation

OriolAbril
Copy link
Contributor

@OriolAbril OriolAbril commented Jun 24, 2025

I have started playing with this a bit in between meetings.
The other place with the "Replacing inline type hint" message wasn't actually being triggered,
I am not sure if it has to do with the condition not being correct or with something else,
I managed to do something similar to the return method in the param method which seems to work.

For now I have updated but kept the messages, however, I think they should not be present by default,
maybe only when requested through a verbosity flag or something.

I also noticed that there are some import related updates. Should these be modified or simply
skipped when keeping the inline type-hint?

Release note

Ensure that existing inline annotations aren't overridden by annotations in
docstrings. This allows documenting types inside docstrings that are not
(yet) supported by Python's type system. Instead more general inlined type
annotations can be used as a fallback.
Previously, annotations in docstrings would take precedence.

OriolAbril and others added 7 commits June 24, 2025 20:40
Keeping parameters is already tested in `override_docstring_param`
above – no need to do so again.
The `underline` method of the `ErrorReporter` includes the underlined
line already.
Also makes sure that imports of a doctype are not unnecessarily
included an inline annotation already exists.
even if a different docstring annotation exists. This is the same
behavior as for parameters and return types.
Probably forgot to do so during debugging.
@lagru
Copy link
Member

lagru commented Jul 12, 2025

Thanks @OriolAbril. I finally got around to reviewing this. I added a few more updates and tweaks. E.g. I also made sure that assignments / attributes behave the same as parameter and return annotations.

@lagru lagru added enhancement New feature or request fix Addresses regressions & bugs labels Jul 12, 2025
Copy link
Member

@lagru lagru left a comment

Choose a reason for hiding this comment

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

Let me know if you want to give it a look. But I think this should work for you. :)

@lagru lagru added this to the v0.4 milestone Jul 12, 2025
@OriolAbril
Copy link
Contributor Author

Thanks! I have done some quick checks and found no issues. Also as the warnings don't fail the respective local pre-commit check I will be able to start adding it to CI without problem from 0.4 onwards 🎉 (I'll probably be back with other issues, but I can always add an inline override as a hotfix now)

@lagru lagru merged commit b7a6437 into scientific-python:main Jul 17, 2025
7 checks passed
@lagru
Copy link
Member

lagru commented Jul 17, 2025

Thanks @OriolAbril for getting this going!

@OriolAbril OriolAbril deleted the type_hint_override branch July 17, 2025 12:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request fix Addresses regressions & bugs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants