Allow disabling only blanket noqa

At the moment, one can disable all use of noqa, but that forbids specific noqa: A000 as well as blanket noqa. As the specific form has many more useful applications than the blanket form, I'd like to be able to configure my projects to allow one but not the other.

mentioned in issue #282

So here's what I've been thinking we might implement this:

Disable all instances of # noqa blanket or specific.

flake8 --disable-noqa all ...

Disable all instances of # noqa that are not specific.

flake8 --disable-noqa blanket ...

Re-enable # noqa when it's turned off in a config file (also the default).

flake8 --disable-noqa none ...

The fun part, however, will be dealing with the fact that this was boolean before and that people may (and likely already are) specifying this in a config file like so.

So what we'll have to do is translate False -> none and True -> all. The trick to this will be people who specify --disable-noqa on the command-line might not have an easy way to transition to this. Especially if they have already done flake8 --disable-noqa ... then we'll have a problem with optparse understanding that in a backwards compatible way. (Even if we were using argparse, that would be unpleasant.)

I'd really rather not add a new option. So here's what I think the path forward looks like:

Add support for parsing False, none, blanket, all, and True along with a deprecation warning that using it as a boolean flag doesn't work. We'll do this in a release like 3.x.0. We'll slate the transition to be 3.x+2.0. So, for example, let's say that we release this compatibility shim with deprecation warning in 3.4.0. We'll cut the plug in the compatibility shim in 3.6.0.

To do this, we'll probably have to:

• Create a callback function to handle the possibility of there being a next arg

  • The callback will need to check the next arg (parser.rargs[0]) to see if it is none, blanket, all.

  • If the callback doesn't find a next argument in those choices, it will need to issue the deprecation warning and then set the value to all.

• Determine how the callback function will interact with how we parse the --disable-noqa value from config files.

  • We might need to introduce some more code/option creation arguments to handle this case if it turns out to be not deterministic/easy

• Document this in the option documentation above and in the option's help text

changed milestone to %3.x.0

added feature:accepted label

I agree with everything you said except for dropping compatibility. Could we do this in 4.x? This makes it more obvious to everybody that there can be deprecation-driven breakage. Doesn't hurt us much to keep the compatibility shim around for a while longer. What do you think?

Could we do this in 4.x?

I don't know when or if we'll have a 4.x.

Doesn't hurt us much to keep the compatibility shim around for a while longer.

Actually, I think this will be problematic enough to begin with that not keeping it longer than we have to would be good for the project. I'm open to keeping it around longer than I originally proposed, but I am not sure I want to commit to keeping it around until 4.x

My point here is that dropping deprecations within one major release will surprise people. I'm sure you have a concrete wishlist for flake8 4.x but if you're unsure this will ever be completed, maybe we should move those ideas to some later release (flake8 5k? ;-)) and just release 3.6.0 as 4.x.