-
When using griffe.load(objspec=package_path, docstring_parser=Parser.numpy) I get a different parsed docstring for my class than if I use Docstring(value=docstring, parser="numpy").parse("numpy") The load() is able to split type annotations if there are multiple given and create Expr objects, but with parse() all type annotations are given as one string (see image below). I'd like to use the Furthermore default values can't be parsed, no what syntax ( Am I missing something or should I create an issue for this? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Hello, thanks for your interest in Griffe 🙂 The difference is that when you load, the docstring parser has access to the actual signatures and can pick up information from them, while when you parse directly, there's no associated object/signature, and therefore less information can be inferred. If you have a look at our docs, we mention that if you want to take full advantage of the parsers, you can manually create objects and attach the docstrings to them before parsing. Obviously it won't be of any help if you don't know these objects and their signature in advance. Unfortunately in that case there's no better solution than loading the whole package. Or maybe you could try loading just a given module, thanks to utilities such as Regarding default values, yes please open a new issue if you think there's something not working correctly. |
Beta Was this translation helpful? Give feedback.
Hello, thanks for your interest in Griffe 🙂
The difference is that when you load, the docstring parser has access to the actual signatures and can pick up information from them, while when you parse directly, there's no associated object/signature, and therefore less information can be inferred. If you have a look at our docs, we mention that if you want to take full advantage of the parsers, you can manually create objects and attach the docstrings to them before parsing. Obviously it won't be of any help if you don't know these objects and their signature in advance. Unfortunately in that case there's no better solution than loading the whole package. Or maybe you could try loading just…