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
mailto:abarnert@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
mailto:tjreedy@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
mailto:tjreedy@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