Skip to content

Warn against user defined __magic__ methods #5940

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
jpy-git opened this issue Mar 20, 2022 · 1 comment
Closed

Warn against user defined __magic__ methods #5940

jpy-git opened this issue Mar 20, 2022 · 1 comment
Labels
Duplicate 🐫 Duplicate of an already existing issue Enhancement ✨ Improvement to a component

Comments

@jpy-git
Copy link
Contributor

jpy-git commented Mar 20, 2022

Current problem

I'm currently working on a PR (#5938) that warns users against manually invoking magic methods.

This led me to wonder what happens if a user defines their own method using the __dunder__ naming convention.

e.g.

class A:
    def __foo__():
        pass

According to the docs

__*__
System-defined names, informally known as “dunder” names. These names are defined by the interpreter and its implementation (including the standard library). Current system names are discussed in the Special method names section and elsewhere. More will likely be defined in future versions of Python. Any use of __*__ names, in any context, that does not follow explicitly documented use, is subject to breakage without warning.

So we should warn users against ever creating a method with that naming convention!

Desired solution

New lint checker that checks for any method definition with a __dunder__ style name that is not an official python __dunder__ method.

Additional context

No response

@jpy-git jpy-git added the Needs triage 📥 Just created, needs acknowledgment, triage, and proper labelling label Mar 20, 2022
@Pierre-Sassoulas Pierre-Sassoulas added Enhancement ✨ Improvement to a component Proposal 📨 Discussion 🤔 and removed Needs triage 📥 Just created, needs acknowledgment, triage, and proper labelling labels Mar 20, 2022
@Pierre-Sassoulas Pierre-Sassoulas added Needs PR This issue is accepted, sufficiently specified and now needs an implementation and removed Proposal 📨 Discussion 🤔 labels Jul 5, 2022
@Pierre-Sassoulas
Copy link
Member

Closing as duplicate of #3038

@Pierre-Sassoulas Pierre-Sassoulas closed this as not planned Won't fix, can't repro, duplicate, stale Jul 5, 2022
@Pierre-Sassoulas Pierre-Sassoulas added Duplicate 🐫 Duplicate of an already existing issue and removed Needs PR This issue is accepted, sufficiently specified and now needs an implementation labels Jul 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate 🐫 Duplicate of an already existing issue Enhancement ✨ Improvement to a component
Projects
None yet
Development

No branches or pull requests

2 participants