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

Config to allow decorators that function like @classmethod #38

Closed
saifelse opened this issue Dec 26, 2016 · 3 comments
Closed

Config to allow decorators that function like @classmethod #38

saifelse opened this issue Dec 26, 2016 · 3 comments

Comments

@saifelse
Copy link
Contributor

In SQLAlchemy, there is a declared_attr decorator that creates class methods:
http://docs.sqlalchemy.org/en/latest/orm/extensions/declarative/api.html#sqlalchemy.ext.declarative.declared_attr

As a result, my codebase is sprinkled with:

class SomeTable(db.Model):
    @declared_attr
    def __table_args__(cls):  # noqa: N805
        ...

It would be nice if we could have a config option that lets us declare if a decorator results in a staticmethod or classmethod as opposed to the implicit default of it being an instance method. I was thinking something like using comma separated list in the setup.cfg/tox.ini file, e.g:

[flake8]
classmethod-decorators=declared_attr
staticmethod-decorators=staticdeco1,staticdeco2
@sigmavirus24
Copy link
Member

This certainly seems reasonable

@saifelse
Copy link
Contributor Author

saifelse commented Jan 2, 2017

@sigmavirus24: do you have any suggestions for testing such a change? I have a working implementation, but the testing framework does not allow custom options to be passed into the NamingChecker.

I'm currently experimenting with the test syntax looking as such:

#: Okay(--staticmethod-decorators=exstatik,stcmthd)
class SecondNewStatic(object):
    @stcmthd
    def test(so, exciting):
        pass

and then parsing the options, which get passed to an instance of flake8.options.manager.OptionManager in ./run_tests.py.

Does this sound like an OK approach to you?

Also, looking at the codebase, I'm unsure which version of flake8 I am using within the test suite. Is it always the latest version?

saifelse added a commit to saifelse/pep8-naming that referenced this issue Feb 16, 2017
- Added support for parsing CLI-style flake8-config parameters,
  with such tests only run in the py27-flake8 and py34-flake8
  test environments.

- Removed support for multiple `codes` in a testcase, since it
  was never used.

Fixes PyCQA#38
saifelse added a commit to saifelse/pep8-naming that referenced this issue Feb 16, 2017
- Added support for parsing CLI-style flake8-config parameters,
  with such tests only run in the py27-flake8 and py34-flake8
  test environments.

- Removed support for multiple `codes` in a testcase, since it
  was never used.

- Add tests for late-decorated methods

Fixes PyCQA#38
saifelse added a commit to saifelse/pep8-naming that referenced this issue Feb 16, 2017
- Added support for parsing CLI-style flake8-config parameters,
  with such tests only run in the py27-flake8 and py34-flake8
  test environments.

- Removed support for multiple `codes` in a testcase, since it
  was never used.

- Add tests for late-decorated methods

Fixes PyCQA#38
saifelse added a commit to saifelse/pep8-naming that referenced this issue Feb 16, 2017
- Added support for parsing CLI-style flake8-config parameters,
  with such tests only run in the py27-flake8 and py34-flake8
  test environments.
- Removed support for multiple `codes` in a testcase, since it
  was never used.
- Add tests for late-decorated methods

Fixes PyCQA#38
@saifelse
Copy link
Contributor Author

@sigmavirus24: just checking to see if there is anything else I need to do on my end to get #39 through. Cheers!

saifelse added a commit to saifelse/pep8-naming that referenced this issue Dec 29, 2017
- Added support for parsing CLI-style flake8-config parameters in tests
  using flake8_polyfill (has a stable API which flake8>=3 lacks)
- Removed support for multiple `codes` in testcases (unused)
- Clean up incorrect usage of default which caused redundant work in
  parse_options for ignore_names

Fixes PyCQA#38
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

No branches or pull requests

2 participants