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

[Andrew Barnert]

On Mar 18, 2015, at 9:52 AM, Nicholas Chammas <nicholas.chammas at gmail.com> wrote:
> 
> I might be wrong, but I see PEP 8 as a living document. If the community believes parts of it are out of date, I would think it's better to update PEP 8 (or issue a replacement PEP) to reflect current thinking.
> 
> Any auto-styling tool included in the standard library would work best if it was based on a written "spec" like PEP 8 (granted, I don't think PEP 8 was meant to be a spec for programmatic implementation, but you get the idea).
> 
> If stuff is not part of PEP 8 that should be, or if parts of PEP 8 are agreed to be "wrong", then PEP 8 should be updated accordingly. Any auto-styling tool, I would hope, would just follow from PEP 8 (or a similar document). The tool should not be the specification.

I agree with all of this.

But that implies that it's worth someone making a spec out of PEP 8. That implies going through PEP 8, getting a sense of what parts are (unambiguously and uncontroversially) mechanizable, and reorganizing and minimally rewriting it to get that sense across. Having numbered rules, and named anchors for each one in the document (or at least to narrower sections, so you can link to something more specific than "Programming Recommendations") would also be helpful. 

I'm not sure such a thing would be accepted if you did it. But it seems like if it were rejected, the standard styler would be no more "standard" than what already exists--and likely to be rejected for the same reasons.

> On Tue, Mar 17, 2015 at 11:42 PM, Alexander Walters <tritium-list at sdamon.com> wrote: 
>> 
>> 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).
>  
> I see what you mean. Several people have made comments to this effect, and this is a good point.
> 
> I guess this is a separate discussion, but is there some way to offer users the advantages of having a library be included with Python without imposing the 2-year release cycle and additional burden on the library's developers?

It depends what you mean.

First, if pip comes with Python, and the library doesn't require C compilation, users already pretty much have that advantage. (And the really nice thing is that 2.7, 3.4, etc. users also have that advantage, which isn't true for something added to the stdlib in 3.5.)

It might even be possible to have language in the official docs and/or the Getting Started or other parts of the site that suggest (as strongly as seems appropriate) that users "pip install autopep8" and use it. (I'm saying "autopep8" as a shorthand for "autopep8, or whatever alternative you'd end up suggesting if you did".)

If the suggestion that IDLE add a graphical package manager wrapping pip goes forward, it could presumably add some kind of "recommended packages" feature, maybe even suggesting it at first run, but it seems like you'd have to jump-start the discussion among IDLE developers and users and then bring it back here, or wait and see if they add such a thing so you can suggest adding autopep8 to the list.

Beyond that, there's really no way to be "included without being included". If it's in the standard source and binary distributions, it's part of the release cycle. I suppose you could have something that came with Python but could be updated with pip, with users strongly suggested to update it--but that doesn't seem like a good idea; if you want to get everyone to pip install -U it, the best way to do that is not to give them an obsolete version, but to just not give it to them. And bootstrapping it the same way as pip doesn't seem reasonable (it's reasonable for pip because "just pip install pip" obviously doesn't work--sometimes, special cases _are_ special enough...). 

One thing that might be reasonable is to include an autopep8 script that runs autopep8 if present, and otherwise just tells you it's not present and suggests pip installing it (similar to what Apple does with Java and X11 binaries). Of course nothing else in Python works that way today, and I suspect a lot of people would resist it, but technically it's certainly doable, if you want to make a case for it.

Finally, remember that not everyone gets Python through an official Python.org installer. Almost every non-Windows, non-mobile platform comes with a "system python", and also has a package manager (possibly third-party, like Homebrew on Mac) that many people who want a different Python turn to. And some people build from source. And others (including on Windows) use third-party Python distributions like Enthought or PythonWin. To these users, what "comes with" Python is not the same thing that Python.org crams into the Windows and Mac installers--and can be much more up-to-date (but isn't automatically, of course). Apple's system Python comes with PyObjC. Some linux distros split off parts of the stdlib into packages named "python-spam" and then have non-stdlib packages in the same repo named "python-eggs". Enthought comes with the SciPy stack, and PythonWin with PyWin32. Anaconda has its own package management system, and a set of recommended extra packages. And so on.

> This seems to be the root of the concern about including, for example, something like autopep8 with Python.
> 
> 
>> On Tue, Mar 17, 2015 at 11:42 PM, Alexander Walters <tritium-list at sdamon.com> wrote:
>> Good coding style really should not be something we ship in the library, it should be something we teach.
> 
> This point is orthogonal to the discussion of whether or not to package an auto-styler, but there are many style points that are so mechanical I see little benefit in expending energy on teaching them. Best would be to automate as much of it away so that people can focus on bigger problems like, what is the right abstraction, did I design this API well, etc.
> 
> Put differently, consider the following straw man: "Good memory management should not be something we ship in the language, it should be something we teach."

That's a great example, because it's a little of both. Python automates memory management as far as is reasonable, and makes it easy for people who need to do more (clear recommendations on when to del/reassign variables, tools like weakrefdict, etc.), so some users don't need to be taught anything, and the more advanced users can be taught more easily than in, say, Objective C.

> There is always something to teach. But when we can automate part of the problem away, I think we generally should.
> 
>> On Wed, Mar 18, 2015 at 4:52 AM, Steven D'Aprano <steve at pearwood.info> wrote:
>> Not necessarily. This list frequently includes half-baked ideas, but the
>> "bigger" the proposal, the more baked it should be to be taken
>> seriously.
> 
> Duly noted!

Also keep in mind that, to whatever extent it isn't fully-baked, it should be clear that it is at least bakeable, and that you look willing and able to do the baking. That's a bit harder for a brand new list member than for, say, Guido (his initial proposal for asyncio, for example, wouldn't have gotten the same interest of it was your initial proposal), but it's doable, and necessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150318/d4750934/attachment.html>