Skip to content
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

support self argument #632

Merged
merged 3 commits into from Jul 6, 2019

Conversation

Projects
None yet
3 participants
@samuelcolvin
Copy link
Owner

commented Jul 1, 2019

fix #629

Checklist

  • Unit tests for the changes exist
  • Tests pass on CI and coverage remains at 100%
  • Documentation reflects the changes where applicable
  • HISTORY.rst has been updated
    • if this is the first change since a release, please add a new section
    • include the issue number or this pull request number #<number>
    • include your github username @<whomever>

@samuelcolvin samuelcolvin force-pushed the self-argument branch from 9f6c4f1 to 85ea317 Jul 1, 2019

@samuelcolvin samuelcolvin changed the title support self argument, support self argument Jul 1, 2019

@skaaptjop

This comment has been minimized.

Copy link

commented Jul 1, 2019

@samuelcolvin so that would work if 'self' is at the root of the dict but if it's nested it doesn't.
e.g.

from pydantic import BaseModel

class Nested(BaseModel):
    self: str

class Model(BaseModel):
    nested: Nested

m = Model.parse_obj({"nested": {"self": "me"}})
#pydantic.error_wrappers.ValidationError: 1 validation error
#nested
# __init__() got multiple values for argument 'self' (type=type_error)
@skaaptjop

This comment has been minimized.

Copy link

commented Jul 1, 2019

That seems to do it.

@codecov

This comment has been minimized.

Copy link

commented Jul 6, 2019

Codecov Report

Merging #632 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #632   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          15     15           
  Lines        2651   2632   -19     
  Branches      524    516    -8     
=====================================
- Hits         2651   2632   -19

@samuelcolvin samuelcolvin merged commit 34f271e into master Jul 6, 2019

5 of 8 checks passed

Header rules No header rules processed
Details
Pages changed All files already uploaded
Details
Redirect rules No redirect rules processed
Details
Mixed content No mixed content detected
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
deploy/netlify Deploy preview ready!
Details
samuelcolvin.pydantic Build #20190706.8 succeeded
Details

@samuelcolvin samuelcolvin deleted the self-argument branch Jul 6, 2019

@dgasmith

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2019

Note that this breaks nested models that overload a BaseModel's __init__.

@samuelcolvin

This comment has been minimized.

Copy link
Owner Author

commented Jul 8, 2019

Humm, hadn't thought of that.

Anything we can do? Or just add a note to the release notes.

@dgasmith

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2019

If I understand the issue correctly, the first argument in the __init__ should be renamed:

class MyClass:

    def __init__(my_custom_self_name, self=5):
        my_custom_self_name = self

a = MyClass(self=3)

print(a.self)

You could even to rename it to something like pydantic_base_model_init to ensure no collisions would occur.

I think supporting canonical init overloading is relatively important. The @validators work really well for most cases, but complex cases where I need to share state before/after the BaseModel init and it starts to become a bit more clunky.

Lnaden added a commit to Lnaden/pydantic that referenced this pull request Jul 8, 2019

Re-allow nested inherited inits without breaking self attribute
This commit enables nested model `__init__` statements to be executed
while still allowing `self` as an argument.

Effectively reverses the changes from samuelcolvin#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.

Lnaden added a commit to Lnaden/pydantic that referenced this pull request Jul 8, 2019

Re-enable nested model init calls while still allowing self
This commit enables nested model `__init__` statements to be executed
while still allowing `self` as an argument.

Effectively reverses the changes from samuelcolvin#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.

@Lnaden Lnaden referenced this pull request Jul 8, 2019

Merged

Re-enable nested model init calls while still allowing self #644

4 of 4 tasks complete

samuelcolvin added a commit that referenced this pull request Jul 11, 2019

Re-enable nested model init calls while still allowing self (#644)
* Re-enable nested model init calls while still allowing self

This commit enables nested model `__init__` statements to be executed
while 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` 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.

* Please Lint

* Please Black

* Update from comments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.