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
Merged

support self argument #632

merged 3 commits into from
Jul 6, 2019

Conversation

samuelcolvin
Copy link
Member

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 changed the title support self argument, support self argument Jul 1, 2019
@skaaptjop
Copy link

@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
Copy link

That seems to do it.

@codecov
Copy link

codecov bot 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
@samuelcolvin samuelcolvin deleted the self-argument branch July 6, 2019 13:22
@dgasmith
Copy link
Contributor

dgasmith commented Jul 8, 2019

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

@samuelcolvin
Copy link
Member Author

Humm, hadn't thought of that.

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

@dgasmith
Copy link
Contributor

dgasmith 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
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.
Lnaden added a commit to Lnaden/pydantic that referenced this pull request Jul 8, 2019
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.
samuelcolvin pushed a commit that referenced this pull request Jul 11, 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 #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
alexdrydew pushed a commit to alexdrydew/pydantic that referenced this pull request Dec 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

How to use a field called "self"
3 participants