Cleaning up the worst pep8 offenses

[Edward K. Ream]

I have just created #584 #584: clean up the worst pep8 offenses.

I welcome all comments. If you do have comments or suggestions, please make them here, not in the issue itself.

Edward

[Terry Brown]

On Sun, 19 Nov 2017 09:35:24 -0800 (PST)
"Edward K. Ream" <edre...@gmail.com> wrote:

> I have just created #584 #584: clean up the worst pep8 offenses

> <https://github.com/leo-editor/leo-editor/issues/584>.

>
> I welcome all comments. If you do have comments or suggestions,

> please make them *here*, not in the issue itself.

I occasionally fix PEP 8 things when I see them, missing spaces after
commas particularly bug me, but I like to keep those changes at least
within a file I'm changing anyway, if not within the part of the file
I'm changing. I feel that PEP-8 is seen as a place to start, not a set
of commandments that must be obeyed. 80 char line length is
particularly dated in today's monitor-scape.
http://jakevdp.github.io/blog/2017/11/09/exploring-line-lengths-in-python-packages/

Hmm, I guess I don't see any harm in hunting PEP-8 things, but it
wouldn't be a priority for me.

Cheers -Terry

[Edward K. Ream]

On Sun, Nov 19, 2017 at 5:09 PM, Terry Brown <terry...@gmail.com> wrote:

> I have just created #584: clean up the worst pep8 offenses
> <https://github.com/leo-editor/leo-editor/issues/584>.

​​

I occasionally fix PEP 8 things when I see them, missing spaces after
commas particularly bug me, but I like to keep those changes at least
within a file I'm changing anyway, if not within the part of the file
I'm changing.

​The beautify* commands will fix such things.

​

I feel that PEP-8 is seen as a place to start, not a set
of commandments that must be obeyed.  80 char line length is
particularly dated in today's monitor-scape.
http://jakevdp.github.io/blog/2017/11/09/exploring-line-lengths-in-python-packages/

​I agree completely.​

Hmm, I guess I don't see any harm in hunting PEP-8 things, but it
wouldn't be a priority for me.

​I've just closed #584.  It turns out that the KeyHandlerClass class uses mixedCase method names consistently.  True, there are other classes in leoKeys.py that use the other way, but that kind of inconsistency can't be helped now.

Furthermore, I think that using the "reloadSettings" name in all classes makes sense, because it creates a different kind of consistency.  Alternatively, we could replace all the reloadSettings methods using a publish/subscribe pattern, but I see no urgent reason not the use the reloadSettings pattern.

In short, there are far bigger issues facing Leo than naming conventions ;-)

Edward

[Matt Wilkie]

This passed off the port bow this evening: https://github.com/hayd/pep8radius. I like the approach, applying pep8 only in the vicinity of where one has recently been working.

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscribe@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Sun, Nov 19, 2017 at 10:51 PM, Matt Wilkie <map...@gmail.com> wrote:

This passed off the port bow this evening: https://github.com/hayd/pep8radius. I like the approach, applying pep8 only in the vicinity of where one has recently been working.

​Interesting, and I like the demo.

For now, I think Leo's beautify commands are good enough.  Note that you can suppress these commands in individual nodes with @nobeautify.

For the most part, though, I think there is lots more to life than pep 8 ;-)

Edward

[jkn]

Just a general reminder for people (like me) who forget this sometimes: the scope of PEP-8 is quite limited:

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

It does not recommend the style for your non-library code, although it is easy to see while people use it for that purpose. Perhaps a 'Leo Code Style Guide', with Edwards deviations from PEP-8, would be useful?

    A-foolish-consistency-ly yours

    Jon N

 

[Edward K. Ream]

On Mon, Nov 20, 2017 at 11:06 AM, jkn <jkn...@nicorp.f9.co.uk> wrote:

Just a general reminder for people (like me) who forget this sometimes: the scope of PEP-8 is quite limited:

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

​Heh.  I never noticed this!​ This makes me very happy.

It does not recommend the style for your non-library code, although it is easy to see while people use it for that purpose. Perhaps a 'Leo Code Style Guide', with Edwards deviations from PEP-8, would be useful?

​The result of the beautify* commands could be called my recommended style.

Many thanks for giving us all a big loophole ;-)

Edward

[Matt Wilkie]

For now, I think Leo's beautify commands are good enough.  Note that you can suppress these commands in individual nodes with @nobeautify.

Thanks for the reminder. I forgot they existed and had been doing things by hand. ;-)