reflect pydantic's type leniency

[samuelcolvin]

pydantic has lots of support for coercing types, however pydantic-pycharm-plugin current gives a message saying simply Expected type "x", got "y" instead:

Is there any possibility to change the error message to something like Field is of type "x", "y" may not be parsable to "x"? (or something cleaner, can't think right now)

Perhaps it might even be possible to not show a warning in some obvious cases eg, int or str when the field is of type datetime? If that's not possible, just making the message more friendly/correct might be simplest.

I can imagine that actually trying to parse the value and see if it'll work (eg. '1' will work for int but 'x' would not) would involve duplicating the whole of pydantic's logic in kotlin which is completely impossible. So I'm definitely not asking for that!

[koxudaxi]

I often think about the situation.

I agree. It's stupid to implement the same logic in kotlin.

I have an idea. The plugin may have a type support list for famous types.
str, int, datetime, datime, etc...

example: {"date": ["str", "int"]}

Also, I guess build script can generate the support list by python.

(eg. '1' will work for int but 'x' would not)

The plugin doesn't know to obtain what value when run.
We may cover the situation with friendly messages.

[samuelcolvin]

Friendly/more correct message is definitely the best first step.

[dmontagu]

I personally would prefer it say something, even if parsing would succeed. Maybe this could be a plug-in option?

(If the point is just to change the warning message then that’s fine with me.)

[samuelcolvin]

is there any option in pycharm for some kind of "weak warning"? That would be optimal.

[koxudaxi]

I guess we need to create a new configuration panel for the plugin.

[dmontagu]

Yes, I'd be fine having it drop to weak warning. My mypy plugin already has configurable strictness, I think, so I'm happy to rely on that beyond weak warnings (though I don't know whether it would be easy or even possible to have a configurable set of "allowed casts" in mypy -- right now, non-strict just means mypy sees a type-hint of Any). It's just nice to get the immediate visual feedback while coding.

I wouldn't be surprised if people wanted to disable the warning entirely though, so I'm still in favor of configurability of the plugin/inspection.

Maybe it would be easier if it were possible to just enable/disable the inspection? I wouldn't care what the default value was -- I'd be happy to manually set it however I wanted it.)

[koxudaxi]

@samuelcolvin
I implemented new features to resolve this problem.
Users can set parsable-type and acceptable-type in pyproject.toml.

• parsable-type may be parsed to a specific type.
  exp. int to datetime.datetime
• acceptable-type can always be parsed to a specific type.
  exp. int to str

This feature is disabled in default.
To enable, Users have to change an inspection of type-checker to new inspection, which has all features of default inspection.

Also, I write how to use the inspection in document pages, and the link is in PyCharm settings.

https://koxudaxi.github.io/pydantic-pycharm-plugin/type-checking/

[tool.pydantic-pycharm-plugin]
# You can select highlight level  from "warning",  "weak_warning", "disable"
parsable-type-highlight = "warning"
acceptable-type-highlight = "weak_warning"

[tool.pydantic-pycharm-plugin.parsable-types]
## datetime.datetime field may parse int
"datetime.datetime" = ["int"]

[tool.pydantic-pycharm-plugin.acceptable-types]
# str field accepts to parse int and float
str = ["int", "float"]

[samuelcolvin]

That's cool. Could you look at the equivalent mypy flag and use that?

[samuelcolvin]

I think we should build a master copy of what types pydantic can accept as inputs to what types, e.g.:

• Ints are always permitted as inputs to datetimes
• Tuples are always permitted as inputs to lists
• Strings are sometimes allowed as inputs to int or float fields - we could provide a regex here to give a better guess
• Same with strings as inputs to datetimes or paths
• Strings are never allowed as the input to a list

I see this information being useful in a number of scenarios:

• To generate docs explicitly (and testably) definiting what pydantic does
• In this plugin and maybe others
• In the mypy plugin

I'll duplicate this to the pydantic repo when I'm back at my desk.

[koxudaxi]

@samuelcolvin

That's cool. Could you look at the equivalent mypy flag and use that?

Did you talk about init_typed and warn_untyped_fields_check_box ?
If I can parse ini file in Java/Kotlin, then I can do it.

I think we should build a master copy of what types pydantic can accept as inputs to what types, e.g.:
I see this information being useful in a number of scenarios:

I agree.
It's a great idea 😄

I'll duplicate this to the pydantic repo when I'm back at my desk.

Thank you very much.