VSCode使用
pydantic works well with any editor or IDE out of the box because it's made on top of standard Python type annotations.
When using Visual Studio Code (VS Code), there are some additional editor features supported, comparable to the ones provided by the PyCharm plugin.
This means that you will have autocompletion (or "IntelliSense") and error checks for types and required arguments even while creating new pydantic model instances.
配置VScode Configure VS Code¶
To take advantage of these features, you need to make sure you configure VS Code correctly, using the recommended settings.
In case you have a different configuration, here's a short overview of the steps.
安装Pylance Install Pylance¶
You should use the Pylance extension for VS Code. It is the recommended, next-generation, official VS Code plug-in for Python.
Pylance is installed as part of the Python Extension for VS Code by default, so it should probably just work. Otherwise, you can double check it's installed and enabled in your editor.
配置你的环境 Configure your environment¶
Then you need to make sure your editor knows the Python environment (probably a virtual environment) for your Python project.
This would be the environment in where you installed pydantic.
配置Pylance Configure Pylance¶
With the default configurations, you will get support for autocompletion, but Pylance might not check for type errors.
You can enable type error checks from Pylance with these steps:
- Open the "User Settings"
- Search for
Type Checking Mode
- You will find an option under
Python › Analysis: Type Checking Mode
- Set it to
basic
orstrict
(by default it'soff
)
Now you will not only get autocompletion when creating new pydantic model instances but also error checks for required arguments.
And you will also get error checks for invalid data types.
Technical Details
Pylance is the VS Code extension, it's closed source, but free to use. Underneath, Pylance uses an open source tool (also from Microsoft) called Pyright that does all the heavy lifting.
You can read more about it in the Pylance Frequently Asked Questions.
配置mypy Configure mypy¶
You might also want to configure mypy in VS Code to get mypy error checks inline in your editor (alternatively/additionally to Pylance).
This would include the errors detected by the pydantic mypy plugin, if you configured it.
To enable mypy in VS Code, do the following:
- Open the "User Settings"
- Search for
Mypy Enabled
- You will find an option under
Python › Linting: Mypy Enabled
- Check the box (by default it's unchecked)
提示和小技巧 Tips and tricks¶
Here are some additional tips and tricks to improve your developer experience when using VS Code with pydantic.
严格错误 Strict errors¶
The way this additional editor support works is that Pylance will treat your pydantic models as if they were Python's pure dataclasses
.
And it will show strict type error checks about the data types passed in arguments when creating a new pydantic model instance.
In this example you can see that it shows that a str
of '23'
is not a valid int
for the argument age
.
It would expect age=23
instead of age='23'
.
Nevertheless, the design, and one of the main features of pydantic, is that it is very lenient with data types.
It will actually accept the str
with value '23'
and will convert it to an int
with value 23
.
These strict error checks are very useful most of the time and can help you detect many bugs early. But there are cases, like with age='23'
, where they could be inconvenient by reporting a "false positive" error.
This example above with age='23'
is intentionally simple, to show the error and the differences in types.
But more common cases where these strict errors would be inconvenient would be when using more sophisticated data types, like int
values for datetime
fields, or dict
values for pydantic sub-models.
For example, this is valid for pydantic:
from pydantic import BaseModel
class Knight(BaseModel):
title: str
age: int
color: str = 'blue'
class Quest(BaseModel):
title: str
knight: Knight
quest = Quest(
title='To seek the Holy Grail',
knight={'title': 'Sir Lancelot', 'age': 23}
)
The type of the field knight
is declared with the class Knight
(a pydantic model) and the code is passing a literal dict
instead. This is still valid for pydantic, and the dict
would be automatically converted to a Knight
instance.
Nevertheless, it would be detected as a type error:
In those cases, there are several ways to disable or ignore strict errors in very specific places, while still preserving them in the rest of the code.
Below are several techniques to achieve it.
在行中禁用类型检查 Disable type checks in a line¶
You can disable the errors for a specific line using a comment of:
# type: ignore
or (to be specific to pylance/pyright):
# pyright: ignore
(pyright is the language server used by Pylance.).
coming back to the example with age='23'
, it would be:
from pydantic import BaseModel
class Knight(BaseModel):
title: str
age: int
color: str = 'blue'
lancelot = Knight(title='Sir Lancelot', age='23') # pyright: ignore
that way Pylance and mypy will ignore errors in that line.
Pros: it's a simple change in that line to remove errors there.
Cons: any other error in that line will also be omitted, including type checks, misspelled arguments, required arguments not provided, etc.
覆盖变量的类型 Override the type of a variable¶
You can also create a variable with the value you want to use and declare it's type explicitly with Any
.
from typing import Any
from pydantic import BaseModel
class Knight(BaseModel):
title: str
age: int
color: str = 'blue'
age_str: Any = '23'
lancelot = Knight(title='Sir Lancelot', age=age_str)
that way Pylance and mypy will interpret the variable age_str
as if they didn't know its type, instead of knowing it has a type of str
when an int
was expected (and then showing the corresponding error).
Pros: errors will be ignored only for a specific value, and you will still see any additional errors for the other arguments.
Cons: it requires importing Any
and a new variable in a new line for each argument that needs ignoring errors.
用 cast
覆盖值的类型 Override the type of a value with cast
¶
The same idea from the previous example can be put on the same line with the help of cast()
.
This way, the type declaration of the value is overriden inline, without requiring another variable.
from typing import Any, cast
from pydantic import BaseModel
class Knight(BaseModel):
title: str
age: int
color: str = 'blue'
lancelot = Knight(title='Sir Lancelot', age=cast(Any, '23'))
cast(Any, '23')
doesn't affect the value, it's still just '23'
, but now Pylance and mypy will assume it is of type Any
, which means, they will act as if they didn't know the type of the value.
So, this is the equivalent of the previous example, without the additional variable.
Pros: errors will be ignored only for a specific value, and you will still see any additional errors for the other arguments. There's no need for additional variables.
Cons: it requires importing Any
and cast
, and if you are not used to using cast()
, it could seem strange at first.
在类参数中配置 Config in class arguments¶
pydantic has a rich set of Model Configurations available.
These configurations can be set in an internal class Config
on each model:
from pydantic import BaseModel
class Knight(BaseModel):
title: str
age: int
color: str = 'blue'
class Config:
frozen = True
or passed as keyword arguments when defining the model class:
from pydantic import BaseModel
class Knight(BaseModel, frozen=True):
title: str
age: int
color: str = 'blue'
The specific configuration frozen
(in beta) has a special meaning.
It prevents other code from changing a model instance once it's created, keeping it "frozen".
When using the second version to declare frozen=True
(with keyword arguments in the class definition),
Pylance can use it to help you check in your code and detect errors when something is trying to set values
in a model that is "frozen".
基础设置并忽略 Pylance/pyright 错误 BaseSettings and ignoring Pylance/pyright errors¶
Pylance/pyright does not work well with BaseSettings
- fields in settings classes can be
configured via environment variables and therefore "required" fields do not have to be explicitly set when
initialising a settings instance. However, pyright considers these fields as "required" and will therefore
show an error when they're not set.
See #3753 for an explanation of the reasons behind this, and why we can't avoid the problem.
There are two potential workarounds:
- use an ignore comment (
# pyright: ignore
) when initialisingsettings
- or, use
settings.parse_obj({})
to avoid the warning
使用Field
添加默认值 Adding a default with Field
¶
Pylance/pyright requires default
to be a keyword argument to Field
in order to infer that the field is optional.
from pydantic import BaseModel, Field
class Knight(BaseModel):
title: str = Field(default='Sir Lancelot') # this is okay
age: int = Field(23) # this works fine at runtime but will case an error for pyright
lance = Knight() # error: Argument missing for parameter "age"
Like the issue with BaseSettings
, this is a limitation of dataclass transforms and cannot be fixed in pydantic.
技术细节 Technical Details¶
Warning
As a pydantic user, you don't need the details below. Feel free to skip the rest of this section.
These details are only useful for other library authors, etc.
This additional editor support works by implementing the proposed draft standard for Dataclass Transform.
The proposed draft standard is written by Eric Traut, from the Microsoft team, the same author of the open source package Pyright (used by Pylance to provide Python support in VS Code).
The intention of the standard is to provide a way for libraries like pydantic and others to tell editors and tools that they (the editors) should treat these libraries (e.g. pydantic) as if they were dataclasses
, providing autocompletion, type checks, etc.
The draft standard also includes an Alternate Form for early adopters, like pydantic, to add support for it right away, even before the new draft standard is finished and approved.
This new draft standard, with the Alternate Form, is already supported by Pyright, so it can be used via Pylance in VS Code.
As it is being proposed as an official standard for Python, other editors can also easily add support for it.
And authors of other libraries similar to pydantic can also easily adopt the standard right away (using the "Alternate Form") and get the benefits of these additional editor features.