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 pylint.pyreverse.inspector #6614

Merged
merged 3 commits into from May 15, 2022

Conversation

DudeNr33
Copy link
Collaborator

  • Write a good description on what the PR does.
  • If you used multiple emails or multiple names when contributing, add your mails
    and preferred name in script/.contributors_aliases.json
    -->
Type
🔨 Refactoring

Description

Add remaining typing to inspector.py.
This was the last untyped module.
After this change I can take a look at the refactoring TODOs we found.

Especially the parts of inspector.py that deal with interfaces and implementation links can be removed in my opinion, as their behaviour is based on the __implements__ attribute which is not a standard Python feature and the corresponding PEP 245 is rejected. Plus, pylint's codebase itself does not use it any more.
Those are also the only places in this module where I used Any.

@DudeNr33 DudeNr33 added pyreverse Related to pyreverse component typing Maintenance Discussion or action around maintaining pylint or the dev workflow labels May 14, 2022
@DudeNr33 DudeNr33 added this to the 2.15.0 milestone May 14, 2022
@DudeNr33 DudeNr33 requested a review from DanielNoord May 14, 2022 14:26
@DudeNr33 DudeNr33 modified the milestones: 2.15.0, 2.14.0 May 14, 2022
@@ -6,22 +6,30 @@

Try to resolve definitions (namespace) dictionary, relationship...
"""
from __future__ import annotations
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
from __future__ import annotations
from __future__ import annotations

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Some day I will learn this! 😄
Maybe that could be a pre-commit check or pylint extension as well?

Copy link
Member

Choose a reason for hiding this comment

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

I'm curious, what is the source for this convention?

Copy link
Member

Choose a reason for hiding this comment

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

PEP8 seems to say the opposite (emphasis mine): Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.

Copy link
Collaborator

Choose a reason for hiding this comment

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

It's my interpretation of PEP8's: You should put a blank line between each group of imports. Since the module docstring is certainly not the same "group" as the future import it makes sense to separate them just like you separate the last import from the first definition.

Note the example just below your quote:

"""This is the example module.

This module does stuff.
"""

from __future__ import barry_as_FLUFL

__all__ = ['a', 'b', 'c']
__version__ = '0.1'
__author__ = 'Cardinal Biggles'

import os
import sys

https://peps.python.org/pep-0008/ for reference.

But, I agree this is somewhat arbitrary. There does seem to be consensus though as psf/black#2996 seems to have general support and would help us with this as well.

Copy link
Member

Choose a reason for hiding this comment

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

Ah, yeah I wondered if that's what you were picking up on. I don't think the document is very clear. I think it's not clear that it's incompatible with "put a blank line before each subsequent group of imports". I'm not going to open a PR against PEP8 (😅 ) but maybe I'll chime in on the black issue, thanks for posting it! EDIT: nah, your example is pretty clear. Thanks for pointing me to it!

Copy link
Collaborator

Choose a reason for hiding this comment

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

I do think a suggestion to edit the PEP and linking to black wouldn't hurt. Just to see if there is actual agreement on it.

If black is going to enforce it it will be pretty "standard" anyway.

Copy link
Member

Choose a reason for hiding this comment

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

I guess I'm feeling we shouldn't enforce this style in pylint or do comments on it. If black changes, we'll get it for free. That example is showing a blank line at the top, but it's not "between" two groups of imports, it's between a docstring, so it's just a random blank line. But no big deal either way obviously.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Fine with me! Agree that increasing maintenance churn for something that is likely auto-fixed by black in a couple of weeks is not worth the effort!

Copy link
Member

Choose a reason for hiding this comment

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

isort is the auto-formatter that should enforce this I think.

pylint/pyreverse/inspector.py Show resolved Hide resolved
pylint/pyreverse/inspector.py Outdated Show resolved Hide resolved
@coveralls
Copy link

coveralls commented May 14, 2022

Pull Request Test Coverage Report for Build 2324292684

  • 29 of 29 (100.0%) changed or added relevant lines in 2 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.002%) to 95.348%

Totals Coverage Status
Change from base Build 2321261148: 0.002%
Covered Lines: 16049
Relevant Lines: 16832

💛 - Coveralls

Copy link
Collaborator

@DanielNoord DanielNoord left a comment

Choose a reason for hiding this comment

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

LGTM!

files: list[str],
func_wrapper: _WrapperFuncT = _astroid_wrapper,
project_name: str = "no name",
black_list: tuple[str, ...] = ("CVS",),
Copy link
Collaborator

Choose a reason for hiding this comment

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

We might want to make this a constant and keep it up to date with pylint's default value for the similar option?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

You mean the black_list / ignore? That would make sense imo.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yes!

@DudeNr33 DudeNr33 merged commit c6d5cfe into pylint-dev:main May 15, 2022
@DudeNr33 DudeNr33 deleted the typing-pyreverse-p4 branch May 15, 2022 06:07
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 pylint or the dev workflow pyreverse Related to pyreverse component typing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants