Skip to content

Class deprecation machinery and mixins #18690

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

Closed
anntzer opened this issue Oct 8, 2020 · 3 comments · Fixed by #18694
Closed

Class deprecation machinery and mixins #18690

anntzer opened this issue Oct 8, 2020 · 3 comments · Fixed by #18694
Milestone

Comments

@anntzer
Copy link
Contributor

anntzer commented Oct 8, 2020

Bug report

In

@cbook.deprecated("3.4")
class Mixin:
    pass

class Base:
    def __init__(self, x): self.x = x

class Mixed(Mixin, Base):
    pass

Mixed(x=1)

the last line raises a rather puzzling

TypeError: object.__init__() takes exactly one argument (the instance to initialize)

because the deprecation machinery grabs object.__init__ to install the deprecation emitter on Mixin. (This is not a theoretical case, see e.g. #18675.)

There's a few possible solutions:

  • "it's too rare, let's not bother"
  • forbid deprecation of classes where __init__ is not defined (which I think is the main failing case)
  • make cbook.deprecated actually create another class that inherits from Mixin and has its own __init__ (which gets wrapped in cbook.deprecated() and just calls super().__init__), instead of monkey-patching Mixin's original __init__.

Matplotlib version

  • Operating system: n/a
  • Matplotlib version: HEAD
  • Matplotlib backend (print(matplotlib.get_backend())): n/a
  • Python version: n/a
  • Jupyter version (if applicable):
  • Other libraries:
@timhoffm
Copy link
Member

timhoffm commented Oct 8, 2020

forbid deprecation of classes where init is not defined (which I think is the main failing case)

Would that raise when I try to deprecate a class? If so, IMHO that's the right amount of effort to put in. The third solution feels a bit over-engineered. And the first might through confusing messages at our users.

@anntzer
Copy link
Contributor Author

anntzer commented Oct 8, 2020

Actually I'll take back what I said, we can't just forbid the deprecation of classes with no __init__, as they're perfectly fine as long as they're not involved in multiple inheritance, and there's actually cases where we deprecate such classes (e.g. currently IgnoredKeywordWarning).

@timhoffm
Copy link
Member

timhoffm commented Oct 8, 2020

So maybe just document that the decorator does not work with multiple inheritance? I don't think it's worth adding heavy machinery for this case.

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 a pull request may close this issue.

3 participants