E701, E302: allowing one-liners for classes

[chrismedrela]

PEP8 allows you to type a bunch of dummy one-liners like this:

class CustomException(Exception): pass
class AnotherException(Exception): pass
class YetAnotherException(Exception): pass

But this code raises E701 (compound statement) and E302 (two lines between classes) errors. I propose to leave compound statements intact if they are a bunch of class/def definitions. This is what I've done in this pull request of autopep8 project: https://github.com/hhatto/autopep8/pull/87, but it wasn't merged since pep8 seems to be a better place for that.

This is not easy to implement since the current framework doesn't allow you to look at the next logical line. This is necessary because you need to look at previous and next line to determine if a definition is alone or inside a bunch of definitions.

[chrismedrela]

I've written a draft to show you my idea.

[KangOl]

How about authorize # noqa comment to disable E701?

[porglezomp]

I see this hasn't had activity in a long time, but I really want this.

[IanLee1521]

Where is the allowance for dummy one liners? The closest I see is in Other Recommendations:

Compound statements (multiple statements on the same line) are generally discouraged.

If that is the only reference, I'm leaning towards closing this and having this tool take the stance that these will always be an error.

[porglezomp]

Under Blank Lines I see:

Blank lines may be omitted between a bunch of related one-liners (e.g. a set of dummy implementations).

This definitely means that

class CustomException(Exception):
    pass
class AnotherException(Exception):
    pass
class YetAnotherException(Exception):
    pass

should be allowed, and I would argue that in the same spirit,

class CustomException(Exception): pass
class AnotherException(Exception): pass
class YetAnotherException(Exception): pass

should probably be allowed. I'd be very happy to only get the former though.

[zackw]

I was just about to post this very bug report. Related cases that should also, IMNSHO, be exempt:

class X:
    def method1(self, *a, **k): raise NotImplementedError
    def method2(self, *a, **k): raise NotImplementedError
    def method3(self, *a, **k): raise NotImplementedError
    ...

and

class UniversalSet:
    """A universal set contains everything, but cannot be enumerated."""
    def __nonzero__(self): return True
    def __contains__(self, obj): return True
    # __len__ is obliged to return a positive integer.
    def __len__(self): return sys.maxsize

[porglezomp]

I'm currently writing a program that's producing a bunch of files with empty stub functions for tools to use, since the real definitions are injected from a host program, and I was hoping I could have them lint cleanly. Unfortunately, this still blocks the nice-looking stubs.

[asottile]

for what it's worth, this has now been relaxed for functions (and probably could also be relaxed for classes as well)

def f(): pass
def g(): pass
def h(): pass

$ ./venv/bin/pycodestyle --version
2.5.0
$ ./venv/bin/pycodestyle t.py
$