Declaring field types as sub-classes of base types gets highlighted in
See original GitHub issueHi, thanks for the great plugin!
Describe the bug
When using sub-classed Constrained*
fields, Expected type '...', got '...' instead.
error is shown.
See this example (using StrictStr
which is inherited from ConstrainedStr
):
It reproduces even when subclassing from base types, ie. str
:
import pydantic
class MyStr(str):
pass
class MyModel(pydantic.BaseModel):
field: MyStr
MyModel(field='')
To Reproduce
Above.
Expected behavior
There’s shouldn’t be error.
Screenshots
Uh, above.
Environments (please complete the following information):
- IDE: PyCharm Professional 2021.1
- OS: Kubuntu 20.04 LTS
- Pydantic Version: 1.8.2
- Plugin version: 0.3.3
Issue Analytics
- State:
- Created 2 years ago
- Comments:8 (3 by maintainers)
Top Results From Across the Web
5.1 Configuring Business Objects with Agile PLM Classes
Object types are organized by the hierarchy of Base Class (a kind of template), Class (more detailed, generally specific to a PLM solution),...
Read more >11.15. Polymorphism — AP CSA Java Review - Obsolete
In Java an object variable has both a declared type or compile-time type and a run-time type or actual type. The declared type...
Read more >Question concerning types, Maps and subclasses in typescript
Firstly, it seems like you want your Chart class to be abstract since you are only ever going to use concrete subclasses of...
Read more >Kinds of types - mypy 0.991 documentation
Declared (and inferred) types are ignored (or erased) at runtime. They are basically treated as comments, and thus the above code does not...
Read more >How To Use Classes in TypeScript | DigitalOcean
In the highlighted code, you added a parameter called name of type string to your class constructor. Then, when creating a new instance...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Some users may want to check strict types strictly. 🤔 This option will cover all case.
This plugin already has supported
Annotated
😉Yeah, that’s true and why not. It just gets tricky quickly and simply staying on top of base types is something that should work sufficiently without extra magic 🌟
So, I think
constrained-type = "lenient"
mode should be a good workaround/escape mechanism when all else fails 😄That’s great. What I mean is that with
Annotated
we don’t need thisconstrained-type = "lenient"
logic at all, because withAnnotated
you always use the base type as the first argument, like:Constrained*
classes andcon*()
methods are not supported withAnnotated
, so there are no sub-types to worry about. But that also means that strict types are not supported now withAnnotated
😢 (as there’s noField(strict=...)
) so it’s sensible to support also non-Annotated
declarations, like you’re about to do here.