Handling reserved names #22
Replies: 4 comments 3 replies
-
This still allows breaking the client using special input - I do not consider this a solution. I'd prefer class AccountTaskExpiryDurationFromCompleteAfter(pydantic.BaseModel):
class Config(pydantic.BaseConfig):
extra = pydantic.Extra.dict
b = AccountTaskExpiryDurationFromCompleteAfter(dict='yes')
b.__dict__["dict"] Which does exactly whats required, accept everything, exposes/overwrites/breaks nothing |
Beta Was this translation helpful? Give feedback.
-
You are right, using dict is opposing the actual idea. |
Beta Was this translation helpful? Give feedback.
-
Take a look how pydantic solves it. They put all data in a dict called I think the BaseModel methods should take precedence, and users could access fields with reserved names explicitly via Other options are field alias for explicit properties, model-global or library-global alias generators. But it would require good name mangling to avoid name clashes. The one I have now (replacing all special characters with underscore) is not enough. |
Beta Was this translation helpful? Give feedback.
-
fields_set = set(values.keys()) storing the data in self.values: Dict and using a ChainMap(self.dict, self.values) in getattr … sounds easy, but is a really hard cut into the pydantic DNA. want to bug @samuelcolvin about it? |
Beta Was this translation helpful? Give feedback.
-
It's a known pydantic limitation and they address it in v2 by using longer names :)
Anything but a pure dict would have some kind of limitation.
One solution would be to use TypedDict, but I'm not too fond of the syntax.
Beta Was this translation helpful? Give feedback.
All reactions