<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 19, 2015, at 5:01 PM, Guido van Rossum <<a href="mailto:guido@python.org" class="">guido@python.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 19, 2015 at 1:40 PM, Terry Reedy <span dir="ltr" class=""><<a href="mailto:tjreedy@udel.edu" target="_blank" class="">tjreedy@udel.edu</a>></span> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""></span>
A program that treats PEP 8 guidelines as rigid rules, that ignores the first guideline "A Foolish Consistency is the Hobgoblin of Little Minds", that removes the human choices intentionally included in PEP 8, is not PEP 8 compliant. I believe one of the motivations for some recent PEP 8 amendments was some unhappiness with pep8.py or other checkers.<span class=""><br class=""></span></blockquote><div class=""><br class=""></div><div class="">I have always been skeptical of automatic style checkers. They encourage a nit-pickish attitude that makes the development process less effective, by encouraging critique of superficial style elements rather than of the code's structure and meaning. In contrast, the intention of PEP 8 was to make code more readable so that its structure and meaning are more easily understood.<br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>My experience is actually the exact opposite. When a machine is responsible for style enforcement people generally don’t feel as bad about being asked to adjust the formatting because it’s just a machine, it can’t make value judgements. When a person asks someone to adjust something to make it easier to read it often times ends up causing a distraction where people tend to feel like since it’s a person asking them to do it they are passing judgement on their code, or they don’t agree with it and since it’s a human saying it it feels more like there is room to budge so you end up with people more likely to be willing to ask for an exemption.</div><div><br class=""></div><div>In my experience projects without mechnical enforcement ends up with massively inconsistent style all throughout the code base. The Python stdlib is a good example of this. Contrast this to projects like <a href="http://github.com/pyca/cryptography" class="">github.com/pyca/cryptography</a> where there is an automated mechanical enforcement of style and it’s got some bare minimum of consistency throughout the entire code base.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Wed, Mar 18, 2015 at 4:38 PM, Andrew Barnert<br class="">
<<a href="mailto:abarnert@yahoo.com" target="_blank" class="">abarnert@yahoo.com</a><br class=""></span><span class="">
<mailto:<a href="mailto:abarnert@yahoo.com" target="_blank" class="">abarnert@yahoo.com</a>>> wrote:<br class="">
<br class="">
But that implies that it's worth someone making a spec out of PEP 8.<br class="">
That implies going through PEP 8, getting a sense of what parts are<br class="">
(unambiguously and uncontroversially) mechanizable, and reorganizing<br class="">
and minimally rewriting it to get that sense across. Having numbered<br class="">
rules, and named anchors for each one in the document (or at least<br class="">
to narrower sections, so you can link to something more specific<br class="">
than "Programming Recommendations") would also be helpful.<br class="">
<br class="">
This is an excellent point and one I did not consider.<br class="">
</span></blockquote>
<br class="">
Having the guidelines numbered (id'ed), even though still regarded as guidelines, could help communication. Checkers could then easily refer to specific guidelines.<br class=""></blockquote><div class=""><br class=""></div><div class="">I worry this will just encourage the nit-picky attitude more.<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Wed, Mar 18, 2015 at 6:17 PM, Terry Reedy <<a href="mailto:tjreedy@udel.edu" target="_blank" class="">tjreedy@udel.edu</a><br class=""></span><span class="">
<mailto:<a href="mailto:tjreedy@udel.edu" target="_blank" class="">tjreedy@udel.edu</a>>> wrote:<br class="">
<br class="">
(Note that autoPEP8 only changes whitespace, which is a small part<br class="">
of PEP 8 recommendations, and the safest aspect of code to change.)<br class="">
<br class="">
Minor point: autopep8 can do more than just whitespace changes with the<br class="">
|--aggressive| flag<br class=""></span>
<<a href="https://pypi.python.org/pypi/autopep8/#more-advanced-usage" target="_blank" class="">https://pypi.python.org/pypi/<u class=""></u>autopep8/#more-advanced-usage</a>><u class=""></u>.<br class="">
</blockquote>
<br class="">
Thanks for the link. I was specifically thinking of global renamings to satisfy PEP 8's Naming Conventions. Idlelib has a mishmash of module and function/method name styles. (I might look and see what can be done with the undocumented (except as 'unstable') libe2to3.)<br class=""></blockquote><div class=""><br class=""></div><div class="">This feels hard to automate, because you don't know what names are part of an external specification.<br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Wed, Mar 18, 2015 at 7:21 PM, Terry Reedy <<a href="mailto:tjreedy@udel.edu" target="_blank" class="">tjreedy@udel.edu</a><br class=""></span><span class="">
<mailto:<a href="mailto:tjreedy@udel.edu" target="_blank" class="">tjreedy@udel.edu</a>>> wrote:<br class="">
<br class="">
We should be careful about adding anything. When we do, we should<br class="">
add libraries, not applications. We should especially not<br class="">
officially endorse one of many opinion-based competitors.<br class="">
<br class="">
I have come around to this view.<br class="">
</span></blockquote>
<br class="">
Accepting this view, we can still ask if the stdlib should have more (policy-neutral) string or list of strings reforming components than it does now. Textwrap has a few functions for strings in general. Idle has about 10 formatting functions exposed on its editor Format menu, but they are not exposed for general use. Tools/Scripts/reindent.py contain some of the same functions as does autopep8. Should there be a code format module that all three, and other programs, could import?<br class="">
<br class="">
Idle and Tools/Scrips/highlight.py both have code to analyze Python code tokens into categories and colorize by category. (Idle uses tkinter tags, highlight.py uses ANSI or HTML tags). Can and should both use a common code analysis function that could be imported? This might actually ease maintainance.<br class="">
<br class="">
Should a generalized 2to3 package be renamed 'codefix' and documented? As 2to3, it is already used by both Tools/Scripts/2to2 and optionally by autopep8, and perhaps by others. I believe it could also be used for some non-2to3 pep8 fixes.<span class="HOEnZb"><font color="#888888" class=""></font></span></blockquote><div class=""><br class=""></div><div class="">I think that a quick "clean up whitespace" feature would be a nice addition to IDLE, provided it's a user-selectable menu items (similar to the existing indent/dedent operations). Refactoring, however, is fiendishly hard for Python -- give it a try in e.g. PyCharm and you will agree.<br class=""></div></div><br class="">-- <br class=""><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" class="">python.org/~guido</a>)</div>
</div></div>
_______________________________________________<br class="">Python-ideas mailing list<br class=""><a href="mailto:Python-ideas@python.org" class="">Python-ideas@python.org</a><br class="">https://mail.python.org/mailman/listinfo/python-ideas<br class="">Code of Conduct: http://python.org/psf/codeofconduct/</div></blockquote></div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">---</div><div class="">Donald Stufft</div><div class="">PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA</div></div></div>
</div>
<br class=""></body></html>