Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Tim Chase <python.list@tim.thechases.com>
Newsgroups: comp.lang.python
Subject: Re: Guido sees the light: PEP 8 updated
Date: Tue, 19 Apr 2016 08:31:01 -0500
Lines: 82
Message-ID: <mailman.12.1461072887.30862.python-list@python.org>
References: <5711c1b3$0$1596$c3e8da3$5496439d@news.astraweb.com> <dne6huFi9sfU1@mid.individual.net> <87shym6kpo.fsf@elektro.pacujo.net> <CAPTjJmrq-pFDGS14PE+FXx=B+fXBD-Pkqc9JdQrjULR9aXRSxg@mail.gmail.com> <mailman.43.1460795561.6324.python-list@python.org> <87h9f26ioa.fsf@elektro.pacujo.net> <1460809922.1918014.580580553.0AE05EE4@webmail.messagingengine.com> <CACwCsY5EG_RFHe8DMF4VStYCsSuO-gMC+KRx05q9=vu8aa3K9g@mail.gmail.com> <mailman.50.1460818461.6324.python-list@python.org> <878u0d7az5.fsf@elektro.pacujo.net> <CACwCsY5fLxQqG80POb=notQdC1T5crarf_aQ2VBkCT2fwZM-2Q@mail.gmail.com> <netsjl$quf$1@ger.gmane.org> <CAMB+yF0XcDSrPWPNYuwq7_99sas4eUoOJm7k-ymoFKDd85saow@mail.gmail.com> <mailman.151.1460986528.6324.python-list@python.org> <m18u0a1uxx.fsf@iKarel.lan> <86twix3mc5.fsf@rudin.co.uk> <87potlrfa1.fsf@elektro.pacujo.net> <20160419083101.5cdfe184@bigbox.christie.dr>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
In-Reply-To: <87potlrfa1.fsf@elektro.pacujo.net>
Precedence: list
Xref: csiph.com comp.lang.python:107322

On 2016-04-19 14:47, Marko Rauhamaa wrote:
> We need a PEP to distinguish also between:
>  - typefaces (Times New Roman vs Garamond)
>  - weights (bold vs thin)
>  - serifs (with or without)
>  - sizes (8pt vs 11pt)
>  - colors (goldenrod vs maroon)

Like HTML & CSS, the goal should be to separate the code (HTML) from
its presentation (how it appears in your editor).

It's why I've taken to using formulaic indenting (one or two
indents depending on whether the continued line starts an
indented block) rather than trying to align with something in a prior
line.  It drives me nuts when I globally change the spelling of
something (and thus the length of some variable name) and then feel
obligated to re-indent my continuations to get them to line back up
with some arbitrary paren.  Compare

    def do_something(param1,
                     param2,
                     param3,
                     ):
        implementation()

with just using

    def do_something(param1,
            param2,
            param3,
            ):
        implementation()

(or, if you want your params to line up


    def do_something(
            param1,
            param2,
            param3,
            ):
        implementation()

which is usually how I end up splitting them)

When "do_something" changes to "frobify", I don't feel the need to go
play with indentation with my scheme.

Likewise, I detest aligning comments and almost always prefer to put
them in a neighboring line if there's continuation:

    foo = bar * 3 + 2 # we have 3 bars
                      # plus one for margin on either side

changing the length of the code portion (say, s/bar/inner_width/) will
require re-indenting (and possibly re-flowing) the comments.

It's even worse if the comment flows to an unrelated line

    foo = bar * 3 + 2    # we have 3 bars
    result = apply(bar)  # plus one for margin on either side

Now, if either line of *code* changes, it requires rejiggering the
comment indentation.

If the comment gets moved above, it's no longer an issue:

    # we have 3 bars plus one for margin on either side
    foo = bar * 3 + 2
    result = apply(bar)

I strongly advocate from keeping the content (the code and its AST)
separate from its presentation.

-tkc