[Python-ideas] gofmt for Python: standardized styling as a language feature

[Cameron Simpson]

On 17Mar2015 23:42, Alexander Walters <tritium-list at sdamon.com> wrote:
>What coding style would be used for such a tool?  PEP-8?  What about a 
>tool for those of us who believe that PEP-8 got a few things wrong?

autopep8 at least lets you pick and choose specific issues to apply or ignore.  
As someone who now aims for a "mostly pep8" style, that is very handy.

Aside: I always wish "fix it" tools to have this kind of granularity. In a 
former life I got to use SGI's C compiler. Like GCC, it had a "lots of 
warnings" mode, somewhat like a builtin lint. _Unlike_ GCC, the SGI compiler 
let one suppress specific warnings, which was very very nice.

>What about for the tribal knowledge that pythonistas develop over time
>that are not part of the standard?  Would such a tool include this?

Such things get progressively harder to formalise into stuff a tool can 
implement. I imagine one could implement quite a lot of knobs, but I also 
imagine that some knobs would require huge code support, and perhaps be 
intrusive enough to make the default knobs (very?) hard to debug/maintain.

Using PEP8 as a guide at least gives a concrete baseline for the feature set.  
I'm not arguing that that is all one should ever want, just that it is well 
defined and very broadly appplicable.

>And what of third party tools that do the same thing?  I have no
>evidence to support this, but I have the feeling that when the
>standard library includes something in a new space, third party work
>in that space slows (json and sqlite come to mind).

Sure. But that isn't always a bad thing; life is too short.

In an ideal world the included battery is amenable to extension and then the 
supplied battery enables faster third party work, at least in the form of 
adding to the battery.

>Good coding style really should not be something we ship in the
>library, it should be something we teach.

Yes and no.

I wholely agree that good style comes from within, and that it should be taught 
"what and why"; blindly applied mechanical style does not itself improve code 
quality. Though having consistent style does at least usually improve code 
readability and maintainability. Not to mention diff noise.

That said, having a tool that will _apply_ a desirable style is very useful.  

Taking myself as an example: my personal library has gads of old code with bad 
style (and bad design choices!) I tend to mostly-PEP8 the old code as I come 
across it during development (committing separately from semantic changes 
unless I've rewritten something outright). That work is slow and incremental.

Having just downloaded autopep8 and given it a tiny trial run against a single 
module I found that a bare run produced a diff of more or less the entire file, 
but adding "--indent-size 2" (my personal major divergence from PEP8) got the 
diff down to a reviewable bunch of small changes, all of which I approve.

Performing that task by hand was an ongoing indefinite inconsistent minor 
improvement activity. Now I can branch and restyle vigorously, because I have a 
tool to do the picky editing. Yay!

Aside: why the bad style from the outset? When coming to a new language or 
system I find it useful to write batteries myself, sometimes because the 
supplied battery does not match my needs but usually because the battery is 
tractable and I learn quite a lot about the problem domain during this process.  
And the same applies to style; my old code has poor style, some leaked across 
from other languages. Having written plenty of code according to my whim, I can 
then look at a suggested style like PEP8 and evaluate it with context. Now I 
mostly aim for PEP8 because I've come to informed decisions about its choices, 
and mostly agree with them.

Metaaside: the above is also something of an excuse for the state of some of 
the code I've put out there:-)

Cheers,
Cameron Simpson <cs at zip.com.au>

Mac OS X. Because making Unix user-friendly is easier than debugging Windows.
- Mike Dawson, Macintosh Systems Administrator and Consultation.
  mdawson at mac.com http://herowars.onestop.net