✨ Allow annotated parsing with a subclass of Path#1183
✨ Allow annotated parsing with a subclass of Path#1183tiangolo merged 6 commits intofastapi:masterfrom
Path#1183Conversation
Path
svlandeg
left a comment
There was a problem hiding this comment.
Hi, thanks for the contribution and feature request!
What you're proposing makes sense to me, and at a first glance the code looks good. Surprisingly, some of the CI tests do fail. Do you have time to look into those?
|
Well - that was a rabbit hole. |
7a8257c to
ae9ddd5
Compare
|
@svlandeg what happens now? |
f367808 to
4d78ba6
Compare
Thank you for the update - I have monkey patched my applications for now. |
4d78ba6 to
40c6e1e
Compare
|
@svlandeg any idea when this will land? Thanks! |
There was a problem hiding this comment.
This is a nice fix that supports subclassing Path cleanly. I verified that the test fails on master and otherwise everything looks good to me.
I'll leave this for Tiangolo for a final check.
Thanks again for your work on this, @emfdavid!
Please allow using custom Path subclasses such as UPath
Here is an example
But as you can see in my debugger, the parsed value will get converted to a Path by the param_path_convertor.
Allowing that function to return anything that is already a Path (or maybe a PurePath?) would fix this issue, though, it maybe a problem for other types as well?
I can hack around this by setting the annotated type to None but using UPath as a parser, however that does not seem to be documented behavior or good practice.