-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-enable nested model init calls while still allowing self #644
Conversation
This commit enables nested model `__init__` statements to be executed while still allowing `self` as an argument. Effectively reverses the changes from pydantic#632 while still enabling the feature it implemented. In theory, there will still be a collision if someone ever tried to use `pydantic_base_model/settings_init` as an arg, but I don't know how to engineer a case where a collision would *never* happen, I'm not sure there is one. This commit also added a test for both BaseModel` and `BaseSettings` for both the `self`-as-a-parameter and the nested `__init__` features since `BaseSettings` now has the same issue as `BaseModel` since it invoked an `__init__` with self. I have added a comment under the `__init__` for both `BaseModel` and `BaseSetting` since not having `self` as the first arg is such a rarity within Python that it will likely confuse future developers who encounter it. The actual name of the variable referencing the class itself can be up for debate.
Thinking about this some more, this does work in the case where the subclass which overwrite's the It might be possible to write a corner case for when someone passes in |
Codecov Report
@@ Coverage Diff @@
## master #644 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 15 15
Lines 2655 2651 -4
Branches 524 524
=====================================
- Hits 2655 2651 -4 |
There is also the option of simply not supporting fields called "self" in the first place as the solution to avoiding that is very non-Pythonic and likely confusing to Python users in the first place (i.e. explicitly reversing #629). I'm also going to continue the discussion on #629 about this though to keep everything in one place. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution, mostly looks good. Dumb of me not to think of this before.
Just a few things to change.
Change Summary
This commit enables nested model
__init__
statements to be executedwhile still allowing
self
as an argument.Effectively reverses the changes from #632 while still enabling the
feature it implemented. In theory, there will still be a collision if
someone ever tried to use
pydantic_base_model/settings_init
as an arg,but I don't know how to engineer a case where a collision would never
happen, I'm not sure there is one.
This commit also added a test for both
BaseModel
andBaseSettings
forboth the
self
-as-a-parameter and the nested__init__
features sinceBaseSettings
now has the same issue asBaseModel
since it invokedan
__init__
with self.I have added a comment under the
__init__
for bothBaseModel
andBaseSetting
since not havingself
as the first arg is such ararity within Python that it will likely confuse future developers who
encounter it.
The actual name of the variable referencing the class itself can be
up for debate.
cc and credit @dgasmith for solution idea
Related issue number
#632 and #629
Checklist
HISTORY.rst
has been updated#<number>
@<whomever>