Require two blank lines *after* a def/class too

[gvanrossum]

The pep8 tool insist on two blank lines before a top-level class or def, but not after one. So you get the following asymmetry:

import stuff


def main():
    blah, blah

if __name__ == '__main__':
    main()

The intention of PEP 8 is to require two blank lines before the 'if' too. I realize the PEP isn't fully clear, since it only says "separate [...] with two blank lines", and if you want an authoritative rule I can rewrite it. Just let me know!

[gvanrossum]

Oh, and clarification: it isn't the 'if' that makes the requirement for two lines. It is the end of the 'def'. The rule I meant to describe is that top-level class and def blocks must be surrounded by two blank lines. (But we need to have an allowance for comments too -- I'll let you figure that out by looking at actual code.)

[IanLee1521]

I believe, though I'm not able to verify this right now, that comments are ignored if before top level definitions. I will double check the exact rules though.

As far as a rule goes, I'm concerned with files such as (specifically lines 98 - 120):

https://hg.python.org/cpython/file/a48e76252952/Lib/json/__init__.py

Where there are ***** assignments and imports that are not two newline separated. Should the two line rule apply only to between top level "class ...", "def ...", and "if name ..." definitions?

[gvanrossum]

Only to top-level class and def.
On Apr 7, 2015 10:49 AM, "Ian Lee" notifications@github.com wrote:

I believe, though I'm not able to verify this right now, that comments are
ignored if before top level definitions. I will double check the exact
rules though.

As far as a rule goes, I'm concerned with files such as (specifically
lines 98 - 120):

https://hg.python.org/cpython/file/a48e76252952/Lib/json/__init__.py

Where there are *** assignments and imports that are not two newline
separated. Should the two line rule apply only to between top level "class
...", "def ...", and "if name ..." definitions?

—
Reply to this email directly or view it on GitHub
#400 (comment).

[jayvdb]

There is ambiguity in the PEP, and differing opinions naturally, regarding whether 'top-level' refers to indentation or scope. e.g. should two blank lines be enforced when the def is within an if?
See #366 and #168 for discussions about that.

[gvanrossum]

By top level I meant scope-wise, not I dentation-wise.

…

--Guido (mobile)

[jayvdb]

Thank you for the clarification.

When "top-level" is scope wise, there is one area where it becomes a little ugly IMO ... between the if and a classdef/def, there should be two lines? e.g.

if True:


    class Foo: pass


...

[gvanrossum]

Yes, go with what feels right to you there.

…

--Guido (mobile)

[sigmavirus24]

By defining top-level as scope-wise, won't this also mean something like:

def func0(foo, bar, bogus):
    biz = ...
    baz = ...


    def inner_func(other_param):
        # ...


    return inner

[sigmavirus24]

Also, I'm guessing we don't consider class definitions as scope in this definition of 'top-level' because then the PEP actively contradicts itself, no?

[gvanrossum]

What about top level is so hard to understand? OF COURSE the inner function is not top level.

…

--Guido (mobile)

[sigmavirus24]

@jayvdb's example is misleading then. Perhaps what you're talking about is

if cond:
    class Foo: pass


    class Bar: pass


    def foo(): pass


else:
     #...

[gvanrossum]

I'm on vacation you have to figure it out by yourself sorry.

…

--Guido (mobile)

[blueyed]

I was using code like the following, which now causes "E305 expected 2 blank lines after class or function definition, found 0":

def foo():
    pass
foo.name = 'bar'

Should this be special cased to allow for setting attributes of the function (and class?) defined above?

The following looks not good:

def foo():
    pass


foo.name = 'bar'

Please let me know if I should create a new issue for this.

[jayvdb]

I think it should be tracked on a separate issue (unless you're intending to do a pull request soon), as I expect a bit of debate about large that special case should be, if at all as pep8 doesnt make an exception for that.
I do agree your previous layout looks nice when it is only a pass or a docstring, but I think it would be mentally jarring if setting the attribute appeared after a large block of function code.

[sigmavirus24]

Should this be special cased to allow for setting attributes of the function (and class?) defined above?

I would argue that the PEP is rather unequivocal that there should be 2 empty lines around functions and class definitions. That said, it also advocates rather strongly for people to come to their own conclusions. Just because pycodestyle 2.1 adds this check, does not mean you have to use it.

[gvanrossum]

I do wonder if there's perhaps a buglet left in the implementation. I was prompted this morning to add a blank line somewhere in the middle of a block of global assignments below a class, here: python/mypy@8c6ba06#diff-2eeaed663bd0d25b7e608891384b7298R87. Note that there already is a double blank line below the class. I almost suspect that it has something to do with the name of the previous assignment being classifiers i.e. starting with class?

[sigmavirus24]

That was fixed in 2.2.0

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[gvanrossum]

I guess somebody should tell the flake8 project. :-) Their setup.cfg requires pycodestyle < 2.2.0...

[IanLee1521]

In their (his) defense, it was only released about 3 hours ago... ;)

[sigmavirus24]

Yeah, someone should tell flake8 that pycodestyle 2.2.0 was released. xD