ENB: Won't do: pep 8 names

[Edward K. Ream]

I recently asked myself whether Leo's code should use Pep 8 naming conventions. The short answer is an emphatic NO! Such changes would have massive impacts on LeoJS and existing Leo scripts.

I entertained this question for two reasons:

- Leo could define an @alias decorator to retain compatibility for class, function, and method names. This decorator would warn (once) about each deprecated name.

- I was thinking of creating tools to make the required changes automatically.

However, the names of routines are only part of pep 8's recommendations. The names of many vars and arguments would also have to change.

Summary

I'm never going to change names extensively within Leo. It's a terrible idea.

Edward

[Thomas Passin]

+1!

[Edward K. Ream]

On Fri, May 5, 2023 at 8:22 AM Thomas Passin <tbp1...@gmail.com> wrote:

+1!

:-) I've considered this several times. Apparently I need constant reminding that this is not a clever idea!

Edward

[jkn]

I've mentioned this before, but note the wording at beginning of PEP-8:

https://peps.python.org/pep-0008/

"This document gives coding conventions for the Python code *comprising the standard library* in the main Python distribution"

*emphasis* mine.

[Edward K. Ream]

On Fri, May 5, 2023 at 3:24 PM jkn <jkn...@nicorp.f9.co.uk> wrote:

https://peps.python.org/pep-0008/

"This document gives coding conventions for the Python code *comprising the standard library* in the main Python distribution"

Pep 8 contains many caveats and subtle points. I don't want to debate those :-)

The mixture of camelCase and underscore_case does sometimes upset newbies, but I think most of us agree that we can't change names.

Edward

[Thomas Passin]

PEP-8 goes on to say -

"... code is read much more often than it is written. The guidelines provided here are intended to improve the readability of code and make it consistent across the wide spectrum of Python code. As PEP 20 says, “Readability counts”."

And

"In particular: do not break backwards compatibility just to comply with this PEP!

Some other good reasons to ignore a particular guideline:

1. When applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP.
2. To be consistent with surrounding code that also breaks it (maybe for historic reasons) – although this is also an opportunity to clean up someone else’s mess (in true XP style).
3. Because the code in question predates the introduction of the guideline and there is no other reason to be modifying that code.
4. When the code needs to remain compatible with older versions of Python that don’t support the feature recommended by the style guide." 

BTW, have you (anyone) tried the easter egg?

import this

[jkn]

Ah, the Zen of Python. Last time I did was about  fifteen years ago ;-o