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

Add typing to metaclass methods #1678

Merged
merged 2 commits into from
Sep 17, 2022

Conversation

DanielNoord
Copy link
Collaborator

Steps

  • Write a good description on what the PR does.

Description

Type of Changes

Type
🔨 Refactoring

Related Issue

@DanielNoord DanielNoord added the Maintenance Discussion or action around maintaining astroid or the dev workflow label Jun 29, 2022
@DanielNoord DanielNoord requested a review from cdce8p June 29, 2022 21:33
def declared_metaclass(self, context=None):
def declared_metaclass(
self, context: InferenceContext | None = None
) -> SuccessfulInferenceResult | None:
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or do we want to assert the infer() to make sure we only return certain types? It doesn't make a lot of sense for a metaclass to be an UnboundMethod (for example), which it could be with the current typing and lack of assertions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I can tell or at least in the astroid tests. Only nodes.ClassDef | None is ever returned. I.e. it could actually make sense to restrict the return type here. Especially since metaclass could be called independently of infer.

I'm not sure how we can add an assert here though without changing the return generator expression. Might be better to use type: ignore or cast instead.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My idea was to change the next call in the return statement to only allow ClassDef to pass through. That should work right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally we should get a warning / error if somehow something else would be returned. Otherwise we might mask an issue that is entirely preventable.

I was also thinking about wether it should be ClassDef or NodeNG. Currently, I would lean towards NodeNG. It might not be as precise, but users can do a simple isinstance check afterwards. Or do you think ClassDef would be better?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally we should get a warning / error if somehow something else would be returned. Otherwise we might mask an issue that is entirely preventable.

I don't really have any idea on how to allow this. Do you want to log something when this occurs?

I was also thinking about wether it should be ClassDef or NodeNG. Currently, I would lean towards NodeNG. It might not be as precise, but users can do a simple isinstance check afterwards. Or do you think ClassDef would be better?

Yeah I think that's better. Especially considering plugins might also set meta classes and might not be as strict as we are.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added the NodeNG check.

@coveralls
Copy link

coveralls commented Jun 29, 2022

Pull Request Test Coverage Report for Build 2587679823

  • 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 92.104%

Totals Coverage Status
Change from base Build 2586018361: 0.0%
Covered Lines: 9402
Relevant Lines: 10208

💛 - Coveralls

Copy link
Member

@Pierre-Sassoulas Pierre-Sassoulas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I'm ok with merging without the coverage, it seems coverall is down.

@DanielNoord
Copy link
Collaborator Author

@cdce8p Gentle ping as this is blocking some other typing work

@DanielNoord
Copy link
Collaborator Author

Merging as I think this is still a good change!

@DanielNoord DanielNoord merged commit 36d2205 into pylint-dev:main Sep 17, 2022
@DanielNoord DanielNoord deleted the typing-metaclass branch September 17, 2022 14:01
cdce8p added a commit to cdce8p/astroid that referenced this pull request Oct 16, 2022
Pierre-Sassoulas pushed a commit that referenced this pull request Oct 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Maintenance Discussion or action around maintaining astroid or the dev workflow
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants