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

Guido van Rossum guido at python.org
Thu Mar 19 22:01:39 CET 2015


On Thu, Mar 19, 2015 at 1:40 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>
> 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.
>

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.


>  On Wed, Mar 18, 2015 at 4:38 PM, Andrew Barnert
>> <abarnert at yahoo.com
>> <mailto:abarnert at yahoo.com>> wrote:
>>
>>     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.
>>
>> This is an excellent point and one I did not consider.
>>
>
> Having the guidelines numbered (id'ed), even though still regarded as
> guidelines, could help communication. Checkers could then easily refer to
> specific guidelines.
>

I worry this will just encourage the nit-picky attitude more.

>
>  On Wed, Mar 18, 2015 at 6:17 PM, Terry Reedy <tjreedy at udel.edu
>> <mailto:tjreedy at udel.edu>> wrote:
>>
>>     (Note that autoPEP8 only changes whitespace, which is a small part
>>     of PEP 8 recommendations, and the safest aspect of code to change.)
>>
>> Minor point: autopep8 can do more than just whitespace changes with the
>> |--aggressive| flag
>> <https://pypi.python.org/pypi/autopep8/#more-advanced-usage>.
>>
>
> 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.)
>

This feels hard to automate, because you don't know what names are part of
an external specification.


>  On Wed, Mar 18, 2015 at 7:21 PM, Terry Reedy <tjreedy at udel.edu
>> <mailto:tjreedy at udel.edu>> wrote:
>>
>>     We should be careful about adding anything.  When we do, we should
>>     add libraries, not applications.  We should especially not
>>     officially endorse one of many opinion-based competitors.
>>
>> I have come around to this view.
>>
>
> 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?
>
> 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.
>
> 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.


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.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150319/cc6ca080/attachment.html>


More information about the Python-ideas mailing list