-
-
Notifications
You must be signed in to change notification settings - Fork 41
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
Boolean operation in NumPy-style type annotation raises error #93
Comments
Parsing the numpy types can be quite hard because they allow free text as well as keywords, here is how we do it in pydoctor: https://github.com/twisted/pydoctor/blob/4176822d7d79e4a55bab6be229266a2c9c85d21b/pydoctor/napoleon/docstring.py#L159 the code is based on sphinx’s napoleon extension. This code could be adapted to output markdown instead of restructuredtext. |
/cc @pawamoy |
I bumped into the same issue I can work around this issue by using |
The core of the issue is to assume the numpy types as parsable with Here are a few examples:
|
Types that are not valid Python (syntax error) are fine indeed. The issue arises when the type is valid Python but not a valid type. Rather than adding complex logic to parse complex Numpy types, we could consider simply ignoring BoolOp errors (as to not make the build fail). If users want automatic cross-reference, they should use valid types and not natural language. What do you all think? |
|
I've decided to use the DEBUG level for such log messages when parsing Numpydoc docstrings. This will prevent your builds from failing on errors or warnings. Other parsers are left untouched and will continue logging errors. |
Thanks, @pawamoy! 🙏 NumPy-style parameter annotations work great now! 🙂 |
Ha, just realized it's you @sisp 😄Nice seeing you here and on Copier's repo! |
Haha, yes, it's a small world it seems. 🤣 I recognized you a while ago on Copier's repo after we had been discussing here for a bit. 😆 |
Thanks! 😄 |
Hi all, |
Describe the bug
A NumPy-style type annotation of the form
A or B
(e.g.int or float
) raises the following error when building MkDocs docs withmkdocstrings
:This issue seems to be related to #82 where the comment
is incorrect according to https://numpydoc.readthedocs.io/en/latest/format.html#parameters.
To Reproduce
Expected behavior
This docstring should parse fine.
System:
griffe
version: 0.22.0The text was updated successfully, but these errors were encountered: