Mypy finds errors in the first example from the documentation

This example

from datetime import datetime
from typing import List
from pydantic import BaseModel

class User(BaseModel):
    id: int
    name = 'John Doe'
    signup_ts: datetime = None
    friends: List[int] = []

external_data = {
    'id': '123',
    'signup_ts': '2019-06-01 12:22',
    'friends': [1, 2, '3']
}
user = User(**external_data)
print(user.id)
print(repr(user.signup_ts))
print(user.friends)
print(user.dict())

$ mypy --strict pydantic_example.py 
pydantic_example.py:3: error: Module 'pydantic' has no attribute 'BaseModel'
pydantic_example.py:5: error: Class cannot subclass 'BaseModel' (has type 'Any')
pydantic_example.py:8: error: Incompatible types in assignment (expression has type "None", variable has type "datetime")

This is not false positive. Pydantic __init__.py uses implicit reexport (this is an error, and I don’t want to ignore it using --no-implicit-reexport), and this example uses None for a non-optional field (this is also an error).

In general, I can’t trust a library that suggests putting None in a non-optional field in the very first example. This violates the mypy type system.

[dmontagu]

This is a problem.

All right, well once your PEP to change mypy errors to syntax errors is accepted, we’ll get right on converting the behavior of every edge case in the use of this library.

[dmontagu]

I agree that the implicit reexport is a nuisance; I think it is worth addressing. @samuelcolvin any ideas?

---

While mypy doesn’t like the following: signup_ts: datetime = None, there is an awkward inconsistency with mypy that this would be allowed as function arguments, and would imply the argument was optional. Given that it raises a mypy error, if you want to pass mypy, of course you should “correct” it. It is valid pydantic though if you choose not to care.

For what it’s worth, there may be times when you explicitly choose to override the annotations and have mypy assume the type is str, but allow it to be None for pydantic (eg, if you know a validator will always make it non-None). Obviously you would want to add # type: ignore but this doesn’t necessarily need to be a part of the documentation.

That said, I’m also not opposed to changing the docs here, PR welcome.

---

In general, I can’t trust a library that suggests putting None in a non-optional field in the very first example.

Well, if you can’t trust the library, you are absolutely free to not use it.

This kind of language is not appreciated by the people who put much of their spare time into this project, and are offering it up to you for free. If you care enough to create an issue, please be courteous and try to phrase your misgivings in a less incendiary way.