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 new domain names options #1106

Merged
merged 5 commits into from Jan 26, 2020
Merged

Conversation

skarzi
Copy link
Collaborator

@skarzi skarzi commented Jan 13, 2020

I have made things!

Checklist

  • I have double checked that there are no unrelated changes in this pull request (old patches, accidental config files, etc)
  • I have created at least one test case for the changes I have made
  • I have updated the documentation for the changes I have made
  • I have added my changes to the CHANGELOG.md

Related issue

Closes: #1103

Introduce 2 new options:

  • --allowed-domain-names - remove given names from variable names'
    blacklist
  • --forbidden-domain-names - extends variable names' blacklist with
    given names

The options listed above are used to create variable names' blacklist
which is leveraged to detect WrongVariableNameViolation violations.

Introduce 2 new options:

+ `--allowed-domain-names` - remove given names from variable names'
  blacklist
+ `--forbidden-domain-names` - extends variable names' blacklist with
  given names

The options listed above are used to create variable names' blacklist
which is leveraged to detect `WrongVariableNameViolation` violations.
Copy link
Member

@sobolevn sobolevn left a comment

Choose a reason for hiding this comment

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

Great work! Thanks a lot!

I have two minor questions and we are good to go.

@@ -109,6 +112,17 @@ def check_attribute_name(self, node: ast.ClassDef) -> None:
naming.UpperCaseAttributeViolation(target, text=target.id),
)

@property
Copy link
Member

Choose a reason for hiding this comment

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

It can be:

  1. Cached
  2. Moved to logic/

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

  1. Cached

Current implementation provide caching, it'a similar to @cached_property from django.
Do you want to introduce new dependency e.g. cached-property just for it?

  1. Moved to logic/

I can move it there if you want, but could you tell me to which file or maybe I should create new one?

Copy link
Member

Choose a reason for hiding this comment

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

You can create a new one 👍

Copy link
Member

Choose a reason for hiding this comment

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

No new dependecies are required, you can try to use lru_cache

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

However when the code responsible for creating variable names' blacklist will be moved to logic/ then it should be enough to just assign the result in __init__:

def __init__(...):
    ...
    self.variable_names_blacklist = logic.create_variable_names_blacklist()

What do you think?

Copy link
Member

Choose a reason for hiding this comment

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

Sounds fine!

*VARIABLE_NAMES_BLACKLIST,
*self._options.forbidden_domain_names,
}
for name in self._options.allowed_domain_names:
Copy link
Member

Choose a reason for hiding this comment

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

Can we use just set arithmetic here?

Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't be an error if allowed and forbidden names intersects?

Copy link
Contributor

Choose a reason for hiding this comment

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

At least, if option variables intersect.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, I agree. But! Only during validation. Not in runtime

Copy link
Collaborator Author

@skarzi skarzi Jan 13, 2020

Choose a reason for hiding this comment

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

is validate_options() proper place to add above mentioned validation logic?

Copy link
Member

Choose a reason for hiding this comment

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

Yeap!

@coveralls
Copy link

coveralls commented Jan 13, 2020

Pull Request Test Coverage Report for Build 2496

  • 23 of 23 (100.0%) changed or added relevant lines in 5 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 100.0%

Totals Coverage Status
Change from base Build 2487: 0.0%
Covered Lines: 5048
Relevant Lines: 5048

💛 - Coveralls

Copy link
Member

@sobolevn sobolevn left a comment

Choose a reason for hiding this comment

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

Awesome progress, thanks again 👍

@@ -45,7 +45,7 @@
class _NameValidator(object):
"""Utility class to separate logic from the naming visitor."""

_variable_names_blacklist: Optional[Set[str]]
variable_names_blacklist: Set[str]
Copy link
Member

Choose a reason for hiding this comment

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

Why is it public?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

To be honest I don't know :D I found it more proper/clear when I was writing this code. I will correct it in following commit

wemake_python_styleguide/logic/naming/blacklists.py Outdated Show resolved Hide resolved
Copy link
Member

@sobolevn sobolevn left a comment

Choose a reason for hiding this comment

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

Awesome! Thanks!

I will merge it into 0.14 release

@sobolevn
Copy link
Member

Merging into 0.14

Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

move some constants to optional configuration options
4 participants