add --classmethod-decorators

[jakkdl]

fixes #74
attributes are currently not handled at all, and not fully obvious how lenient/strict we want to be. As a first pass I'll probably require a full match, but if so one might want to support wildcards, otherwise we should maybe just match the final name. I'll probably go read up on how I handled stuff in flake8-trio and see if I can find the motivation

Should you require re-specifying staticmethod if specifying --classmethod-decorators? That's how pep8-naming does it, but I have a very hard time seeing why you wouldn't want it enabled.

TODO:

• handle attributes in a sensible way
• write documentation in README.md
• duplicate tests for metaclass
• double check that it works to read from config or command line
• handle [pydantic].validator by default

[jakkdl]

Hm, looks like the test fail is from master.

[Zac-HD]

• I'd avoid wildcards, and check whether the (possibly-dotted) name is in the list
• I'd also make configuring the list add to the defaults, not replace them. I'd guess pep8-naming did the latter just because as the default argparse behavior that's a bit easier.

[EldarSehayekZenity]

Pydantic also has "root_validator" in 1.x versions, would be great to have it included by default as well

[jakkdl]

I'm slightly hesitant to add several default decorators, if you can only extend and not replace the decorator list, especially given that matching on attributes is done only on the last part of the name. So if somebody were to add @my_static_decorators.validate it'd match against the default validate and there would be no way around it other than renaming their decorator or switching to pep8-naming. But the gain in ease-of-use for most users might outweigh the downsides.

Alternatively I could deviate from pep8-naming's functionality, and make @obj.name not match name, and have the default list be classmethod, pydantic.validator, validator, pydantic.root_validator, root_validator which slightly alleviates the above scenario.

A bigger issue: It seems it's not possible to specify the same option in several flake8 plugins, I could maybe try to check the currently loaded plugins by digging into flake8 internals and only register --classmethod-decorators if pep8-naming isn't installed - but it seems possibly wise to go with a different option name, especially if we start veering away from having the exact same functionality.

[Zac-HD]

Going with "replace, but have better defaults than pep8-naming" would probably solve this just fine for almost everyone? We could also send them a PR once we've decided, so we have the same defaults 🙂

[jakkdl]

@Zac-HD what about the name conflict? --bugbear-classmethod-decorators? --b902-classmethod-decorators? Or dig around in flake8 internals

[Zac-HD]

Hmm, can we ensure that we're loaded after pep8-naming? If so, we could do something like HypothesisWorks/hypothesis@942db62 to either add the arg or just change the defaults when bugbear gets loaded... definitely a tricky internals hack but it'd be a nice user experience if it works reliably.

[jakkdl]

okay that wasn't too tricky to resolve. Maybe some minor polish left but otherwise this is finished

[Zac-HD]

Tiny docs nitpicks, but this looks great and otherwise ready to merge! Thanks again @jakkdl 😁

[jakkdl]

double-checked that it works when specified on the command line, and if specified in the config file (though got tripped up for a minute by the duplication between setup.cfg and .flake8). Also duplicated the tests for metaclasses, and broke out the logic to a helper function.

[cooperlees]

Thanks for all the efforts here and reviews all. I think this will be welcomed by many. I'm happy to merge and release this ...