1.9.1 Breaking change with model deep copying

[NotPeopling2day]

Checks

• I added a descriptive title to this issue
• I have searched (google, github) for similar issues and couldn't find anything
• I have read and followed the docs and still think this is a bug

Bug

https://github.com/samuelcolvin/pydantic/pull/3642/files
The above PR changes the way models are copied and has created a breaking change in our code base. When running our test suite we now get the following error:

INTERNALERROR>   File "/Users/worx/ape/src/ape_test/providers.py", line 19, in __init__
INTERNALERROR>     super().__init__(**data)
INTERNALERROR>   File "pydantic/main.py", line 339, in pydantic.main.BaseModel.__init__
INTERNALERROR>   File "pydantic/main.py", line 1038, in pydantic.main.validate_model
INTERNALERROR>   File "pydantic/fields.py", line 857, in pydantic.fields.ModelField.validate
INTERNALERROR>   File "pydantic/fields.py", line 1074, in pydantic.fields.ModelField._validate_singleton
INTERNALERROR>   File "pydantic/fields.py", line 1121, in pydantic.fields.ModelField._apply_validators
INTERNALERROR>   File "pydantic/class_validators.py", line 313, in pydantic.class_validators._generic_validator_basic.lambda12
INTERNALERROR>   File "pydantic/main.py", line 679, in pydantic.main.BaseModel.validate
INTERNALERROR>   File "pydantic/main.py", line 605, in pydantic.main.BaseModel._copy_and_set_values
INTERNALERROR>   File "/Users/worx/.pyenv/versions/3.9.2/lib/python3.9/copy.py", line 146, in deepcopy
INTERNALERROR>     y = copier(x, memo)
INTERNALERROR>   File "/Users/worx/.pyenv/versions/3.9.2/lib/python3.9/copy.py", line 230, in _deepcopy_dict
INTERNALERROR>     y[deepcopy(key, memo)] = deepcopy(value, memo)
INTERNALERROR>   File "/Users/worx/.pyenv/versions/3.9.2/lib/python3.9/copy.py", line 151, in deepcopy
INTERNALERROR>     copier = getattr(x, "__deepcopy__", None)
INTERNALERROR>   File "/Users/worx/ape/src/ape/api/networks.py", line 183, in __getattr__
INTERNALERROR>     return self.get_network(network_name)
INTERNALERROR>   File "/Users/worx/ape/src/ape/api/networks.py", line 320, in get_network
INTERNALERROR>     raise NetworkNotFoundError(network_name)
INTERNALERROR> ape.exceptions.NetworkNotFoundError: No network named '--deepcopy--'.

Pinning to 1.9.0 as current fix.

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

pydantic version: 1.9.1
            pydantic compiled: True
                 install path: /Users/worx/.pyenv/versions/3.9.2/envs/ape/lib/python3.9/site-packages/pydantic
               python version: 3.9.2 (default, Dec  2 2021, 09:57:33)  [Clang 13.0.0 (clang-1300.0.29.3)]
                     platform: macOS-12.3.1-arm64-arm-64bit
     optional deps. installed: ['typing-extensions']

import pydantic

...

[samuelcolvin]

Thanks for reporting, please can you provide a self contained example that shows the error.

[timkpaine]

I am experiencing the same, references that would've previously been carried through a hierarchy of types now get broken during validation. I will try to put together a repro and suggest changes to maintain the prior functionality

[timkpaine]

ae40832

[timkpaine]

here is a fine repro:
https://github.com/PrettyWood/pydantic/blob/ae408326e70d84510a8e25e8f6a6ae8871df2fd0/tests/test_main.py#L1564

That line was changed from is to is not. This is a breaking change in functionality

[samuelcolvin]

Well that's not the same as the error shown above, that's just a change in behaviour.

[timkpaine]

sure, but its a breaking change in behavior.

[timkpaine]

#4093

[NotPeopling2day]

Yeah, the breaking change in behavior on a minor release was my intention in creating the ticket, more info driven than anything. We've corrected the issue on our side by changing back to the previously default behavior for copy_on_model_validation. ApeWorX/ape#735 , without updating this setting in the config we end up seeing seg faults.

[orenwang]

I am experiencing the same. Had to downgrade to 1.9.0 to make my code work.

[gdalmau]

@samuelcolvin @NotPeopling2day I think this issue can be closed since it was fixed in https://github.com/pydantic/pydantic/releases/tag/v1.9.2 with #4093

[samuelcolvin]

Good catch, thanks.