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

[Terry Reedy]

On 3/19/2015 10:32 AM, Nicholas Chammas wrote:
> OK, I hereby abandon this proposal. :)

Thank you for being so sensible ;-)

Let me first quote (out of order) your conclusion:

 > I think any part of the development process we automate
 > away is a good thing (stdlib inclusion or not notwithstanding).>

I agree, which is why I expect to do some work making it easier to 
download 3rd party modules and apply them to python code, both in a gui 
IDE framework (Idle).  I think automation should respect and augment, 
not replace. the human programmer.

> To summarize the conclusion I believe this thread has arrived at:

...

>     Ignoring that difficulty, there is also the problem of what “spec”
>     to use for any such auto-styler. PEP 8 is an obvious choice, but it
>     was written as a guide for humans, not a spec for programmatic
>     implementation.

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.

 >     Furthermore, there are doubts about PEP 8’s utility
>     as the basis for a universal auto-styler, as it was intended for
>     code specifically in the Python standard library.

Pydev is a relatively small group of volunteers who otherwise work 
either for themselves or for various organizations scattered around the 
world.  Having the freedom to put actual readability ahead of rigid 
consistency makes volunteering more attractive.  I regard code as a form 
of poetry, but prefer a flexible but defined structure to free-form 
mishmash.

Google, as an example, is a very large corporation that pays people well 
to adhere to its guidelines and rules.  This is a different situation 
and its best choice for Python styling may well be different from pydev.

> 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.

> 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.)

> 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.

-- 
Terry Jan Reedy