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

super().__init__ doesn't work in explicit protocol subclasses #572

Closed
ilevkivskyi opened this issue Jul 13, 2018 · 6 comments
Closed

super().__init__ doesn't work in explicit protocol subclasses #572

ilevkivskyi opened this issue Jul 13, 2018 · 6 comments

Comments

@ilevkivskyi
Copy link
Member

A possible solution is to append a call to existing __init__ while overwriting (after the check for _is_protocol=True, where we unconditionally raise because protocols can't be instantiated). This way explicit non-protocol subclasses can use a protocol __init__ as a "default constructor". Default implementations are already supported for other protocol members, so it is natural to expect that __init__ is not different. See also python/mypy#3823

cc: @JukkaL

@ilevkivskyi ilevkivskyi changed the title super().__init__ is not called in explicit protocol subclasses super().__init__ doesn't work in explicit protocol subclasses Jul 13, 2018
@grahamc
Copy link

grahamc commented May 18, 2020

I have run in to this problem with @adisbladis, and he came up with this workaround:

if not TYPE_CHECKING:
    from typing import Generic
    Protocol = Generic
    def runtime_checkable(f):
        return f
else:
    from typing_extensions import Protocol, runtime_checkable

I accidentally commented this on #561 at first, my apologies.

adisbladis added a commit to grahamc/nixops that referenced this issue May 18, 2020
Explicitly subclassed Protocols don't support super().__init__
... but we need that.

See: python/typing#572 for a description, including
the below workaround.

Protocol doesn't give us any special run-time behavior (except for
runtime_checkable,) and can be pretty transparently swapped out for
Generic at run time.

By using Generic at run-time, we get the expected __init__ behavior.

But, we still want Protocols at type-checking time because Protocol
is much stricter about assigning to `self` without explicitly defining
and typing the object variable.

In conclusion, I'm sorry. Hopefully
python/typing#572 gets fixed and we can
delete this and go back to the isinstance check in deployment.py.

Co-authored-by: Graham Christensen <[email protected]>
adisbladis added a commit to grahamc/nixops that referenced this issue May 18, 2020
Explicitly subclassed Protocols don't support super().__init__
... but we need that.

See: python/typing#572 for a description, including
the below workaround.

Protocol doesn't give us any special run-time behavior (except for
runtime_checkable,) and can be pretty transparently swapped out for
Generic at run time.

By using Generic at run-time, we get the expected __init__ behavior.

But, we still want Protocols at type-checking time because Protocol
is much stricter about assigning to `self` without explicitly defining
and typing the object variable.

In conclusion, I'm sorry. Hopefully
python/typing#572 gets fixed and we can
delete this and go back to the isinstance check in deployment.py.

Co-authored-by: Graham Christensen <[email protected]>
@Yobmod
Copy link

Yobmod commented Aug 9, 2021

Hi, I've just come across this in our testing when updating from 3.10.0.b4 to 3.10.0.rc1.
There's been some change made to protocols for 3.10.0 that change runtime behaviour?

In my case, the protocol classes don't have an __init__(), so I didn't expect them to cause an error, and they didn't with 3.8 or 3.9.

I can't see what the change is in the 3.10 release notes, maybe the fix for runtime_checkable protocols with only attributes? (But we have methods, just no init().)

@grahamc
Copy link

grahamc commented Aug 9, 2021

@Yobmod this bug has been open for 3 years, I wonder if you did some research that ties such a very recent change to this bug in particular?

@hauntsaninja
Copy link
Collaborator

hauntsaninja commented Aug 9, 2021

@Yobmod
Copy link

Yobmod commented Aug 9, 2021

@hauntsaninja Thanks for the heads-up! (I put in a workaround for now, but I'll check if fixed next rc).

@srittau
Copy link
Collaborator

srittau commented Nov 4, 2021

Closing here as this has been filed to bpo.

@srittau srittau closed this as completed Nov 4, 2021
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

No branches or pull requests

5 participants