Open Vodes opened 4 months ago
Hi @Vodes, thanks for the report.
For future reference and ease of reading, could you add a snippet showing your Pydantic dataclass declaration?
Yeah no problem. The class that is also used in the screenshots is defined right here. The config being used is in this seperate file to not clutter up everything else.
Thanks, let me update the issue body with these.
I suppose we will have to somehow duplicate the code of our built-in dataclasses
extension into the sponsors-only pydantic
extension, with additional logic since Pydantic's dataclasses allow a few more things. I'll mark this as feature request instead of bug!
So I understand, this is out of scope for griffe without the extension? I'm not really interested in pydantic stuff outside of the dataclass and I only really care about the actual attributes being presented properly.
Yep, what we incorporate in Griffe is support for the standard lib and the Python language itself. Dataclasses, even though standard, are a bit special (and quite hard to handle statically) so they are supported through a built-in extension.
Pydantic models and dataclasses are third-party, so they are handled through an external extension.
If you don't want to become a sponsor 😜 and rely on the Pydantic extension, you could try to force dynamic analysis on such dataclasses (which could help for the issue here). I'll add an example on how to do that in the docs 🙂
Hey so I just noticed that there were some docs related commits lately but would you mind pointing me in the right direction of what I should enable to make this work?
I didn't want to bump this but I assume now that the extension is public this isn't really a concern anymore. Feel free to close if so.
Sorry, missed your previous reply. By the way, feel free to ping me if I don't answer in the future (that's what my GitHub status say :smile:!).
The griffe-pydantic extension just became public indeed (thanks to my awesome sponsors :rocket:), but it doesn't have any kind of support for Pydantic's dataclasses yet, so I believe we can keep this open.
Description of the bug
Griffe fails to parse the class init signature for pydantic dataclasses that allow extra kwargs. The result is missing types in the documentation and everything marked as required.
To Reproduce
Install the package with the
dynamic-dataclasses
branch.pip install git+https://github.com/Jaded-Encoding-Thaumaturgy/muxtools.git@dynamic-dataclasses
And then either use the docs repo itself like
http://localhost:8000/muxtools/audio/encoders/ will then show the issue.
or just use a blanket docs setup that just embeds the encoders file like this
Full traceback
Full traceback
```python WARNING - griffe: C:\Users\Alex\AppData\Roaming\Python\Python312\site-packages\muxtools\audio\encoders.py:274: Parameter 'bitrate_mode' does not appear in the function signature WARNING - griffe: C:\Users\Alex\AppData\Roaming\Python\Python312\site-packages\muxtools\audio\encoders.py:274: No matching parameter for 'bitrate_mode' WARNING - griffe: C:\Users\Alex\AppData\Roaming\Python\Python312\site-packages\muxtools\audio\encoders.py:274: Parameter 'bitrate' does not appear in the function signature WARNING - griffe: C:\Users\Alex\AppData\Roaming\Python\Python312\site-packages\muxtools\audio\encoders.py:274: No matching parameter for 'bitrate' WARNING - griffe: C:\Users\Alex\AppData\Roaming\Python\Python312\site-packages\muxtools\audio\encoders.py:274: Parameter 'cutoff' does not appear in the function signature WARNING - griffe: C:\Users\Alex\AppData\Roaming\Python\Python312\site-packages\muxtools\audio\encoders.py:274: No matching parameter for 'cutoff' ... ```Expected behavior
Properly parse types in the signature. Using a vanilla python dataclass results in the wanted behavior.
Environment information
Boost priority