On pydantic v1 (v2 seems to work fine), PrivateAttrs initialization is pretty intricate and our pickling (not us but cloudpickle) in an unclear way seems to be messing with the order of attribute setting and results in private attrs finding their way into __dict__ of the model and so into its dict() as well, even though they are also in __private_attributes__. I dug around, but I think in interest of time we are better off not using them for now. General feeling is that PrivateAttrs are not too common (we don't use it anywhere else in the whole org) and, esp in v1, are pretty fragile/buggy (https://github.com/pydantic/pydantic/issues/7142, https://github.com/pydantic/pydantic/discussions/3480).
On pydantic v1 (v2 seems to work fine),
PrivateAttr
s initialization is pretty intricate and our pickling (not us but cloudpickle) in an unclear way seems to be messing with the order of attribute setting and results in private attrs finding their way into__dict__
of the model and so into itsdict()
as well, even though they are also in__private_attributes__
. I dug around, but I think in interest of time we are better off not using them for now. General feeling is thatPrivateAttr
s are not too common (we don't use it anywhere else in the whole org) and, esp in v1, are pretty fragile/buggy (https://github.com/pydantic/pydantic/issues/7142, https://github.com/pydantic/pydantic/discussions/3480).We kinda made this work before https://github.com/fal-ai/fal/pull/155/files#diff-455e7b832e183d2693a3af34285fdc92b599e8836ff14c4acb47af78e56e2cacR85 by setting the
_file_data
beforesuper().__init__
but that was probably an accident.