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 |
|
You are right, using dict is opposing the actual idea. |
|
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. |
|
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? |
Uh oh!
There was an error while loading. Please reload this page.
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.
All reactions