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:
     #...