BaseModel.construct returns instances with None assigned to fields with a default_factory

[zoopp]

Bug

Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":

             pydantic version: 1.6.1
            pydantic compiled: True
                 install path: /home/mihai/.virtualenvs/pydantic/lib/python3.8/site-packages/pydantic
               python version: 3.8.3 (default, May 17 2020, 18:15:42)  [GCC 10.1.0]
                     platform: Linux-5.7.7-1-ck-x86_64-with-glibc2.2.5
     optional deps. installed: ['devtools']

from pydantic import BaseModel, Field
from typing import List

class Model(BaseModel):
    foo: List[int] = Field(default_factory=list)
    bar: str = 'Baz'

print(Model.construct()) 

# in pydantic   1.5.1 the result is: foo=[] bar='Baz'
# in pydantic  ^1.6.0 the result is: foo=None bar='Baz'

Hello, I'm using pydantic in an application and after updating to v1.6.1 from v1.5.1 I came across this situation which results in a couple of failures.

From the changelog and documentation it's not clear if this change was intended or not.

[PrettyWood]

Hi @zoopp,
Well we made some changes on default_factory to avoid calling it for nothing and avoid some side effects in #1504 and #1712
But this line changes the default value that used to be set in v1.5.1 hence the None.
You could just use Model() instead of Model.construct() to fix this issue in the meantime.
I don't know what we really want in term of behaviour to

• avoid calling default_factory when not needed
• still have meaningful default values with construct

[zoopp]

Thank you for the reply @PrettyWood,

It's okay, I can work around the issue until a consensus is reached on what the behavior should be. Speaking from my point of view, or more generally from a user of the library's point of view, I would say it would make sense that if construct initializes fields with default values then it should initialize fields with default_factory as well.

Would it make sense to call the factories inside the construct method as needed?

[PrettyWood]

@zoopp I'll try to work on this bug soon. I agree the behaviour should be the same as calling Model.__init__ in term of fields and set values. There is a very easy fix but it's quite ugly and I'd like to take a bit more time to see if we can find a cleaner solution

[PrettyWood]

@zoopp I opened a PR with a proposal to support default_factory properly. Your feedback is welcome :)

[zoopp]

I looked over the PR and from my point of view it seems well done. I've tested your fix in my application as well and things work without any issues.

Awesome job! 👍