RFC: Exceptions to PEP-8 Adoption for RTEMS Tools

[Amar Takhar]

On 2020-03-19 10:00 -0600, Gedare Bloom wrote:
> Thank you for kicking off this discussion. As with most style issues,
> a lot of personal preferences came out, but also some good reasoning
> was given on both sides.

Yeah, I know these conversations sometimes don't go well but everyone has been 
bringing up great points.




> > Python itself has not followed this rule for a long time you can see many lines
> > over 80 in the Python source itself.
> >
> > Also, due to the nature of the language most lines end up below 80 characters
> > anyway.  Python is not an easy language to read when you have to break long
> > lines into 2 especially when you start breaking up strings.
> >
> Possibly, although as pointed out by others, some nasty Python can be
> written in one line, especially if you allow nested list
> comprehensions. There is certainly a balance to strike.

Absolutely I agree and this is why I hightlighted issues of where it makes sense 
to keep them long.  We already have examples of this in our own Python code.

do we now go back and shorten all of those?  They're far easier to read the 
way they are now.

And while it may be hard to believe I've absolutely run into young, new 
developers who are confused when seeing line breaks especially when they're 
multi-line.

The amount of times we need to even break lines should be far and few between 
that's a Python programming issue less than a 80 character limit problem.  
There's no need to stack functions it's better to have variables for clarity or 
split it in multiple lines avoiding the usage of '\'.

The times where going beyond 80 make sense you can see this in the Python source 
itself as well as in rtems-tools breaking it up would make it hard to read to 
save what, 5 characters?


> > I'm with most of the developers here -- 80 characters as been the norm for a
> > very long time however this is no longer true for new developers.  There are
> 
> I do realize new/young developers use and enjoy long lines. I'm sure
> this is a result of increasing screen sizes/resolutions over the last
> 2 decades. I understand it may bother such developers to adhere to
> line length limits that seem arbitrary and arcane. However, reasons
> given elsewhere for 80-character limit are also compelling. I see this
> trend of relaxing the line limit as purely for the convenience of
> personal preferences, other than the possible argument that breaking
> apart long lines is more confusing than leaving them intact. That
> argument I can't really debate or judge; it would make an interesting
> study though.

I don't think it's fair to say they enjoy it.  I think we enjoy short lines far 
too much.  It's easier for us to deal with a line that's 5 or 10 characters too 
long than it is for a new developer to deal with line breaks.  This isn't just 
about breaking lines, too you bring up a point lower that my example would be 
easier to read.

So, then how do we setup rules in how to break up a long line?  While I don't 
have any source I can show I can tell you those splits become arbitrary.  As 
close to 80 characters as it can be and then '\'.

If you aren't experience with splitting lines it has no meaning it's just about 
breaking the long line up not keeping it easy to read.  Are we then going to 
start rejecting patches because the way it was broken doesn't make sense?

We had dozens of rejections at one company because developers were breaking 
strings up when the whole string should have been moved one line lower it's 
obvious to us but not to someone who isn't used to it.


> Maybe. I sent a patch to do exactly that as a simple POC. I actually
> think it is more readable with it split, since there is embedded
> control flow in that long line.

Sure but there are dozens of examples of this and I don't think there is any 
point in changing any of them.


> > I've ran into this more than once where a Python developer ends up in confusion
> > when reading source that has line breaks to keep under line lengths.
> >
> I understand this also. Hopefully we can find good ways to break apart
> long lines or refactor long lines to several lines to reduce
> confusion. In general I think we can all agree that simplicity reduces
> confusion. That isn't to say shorter lines are simpler (e.g., some of
> John Carmack's nasty C code), but they should encourage less
> complexity on average I would imagine.

I don't see any reason to raise the barrier for entry into programming Python 
for RTEMS.  Writing C is hard enough Python can be enjoyed by anyone I'm not 
suggesting we accept bad Python code at all.


> > I'd like to go the direction the wind is blowing on this and relax this rule to
> > 120 for source, 80 for documentation where possible.
> >
> One question raised, which is really valid, is whether existing
> formatters/checkers can be easily configured to filter for this hybrid
> rule on line length for source vs comments. But, since it seems the
> majority vote is for 80-character limit, the question isn't terribly
> relevant now.

Yes there are checkers that do this.  There is a flack8 version out there that 
allows for nominal variances like 5, 10, 15%.

Here is a fantastic talk from Raymond Hettinger about this.  The whole talk is 
great but please watch 5 mins starting from this point:

  https://youtu.be/wf-BqAjZb8M?t=1183


I absolutely encourage anyone here who is for the 80 character limits to watch 
this talk he highlights many salient points far better than I can.

Pedantic PEP8 makes for bad Python he proves that in his talk.  We should care 
more about our code being intelligible *Python*.  Python is not C, when you 
write Python well long lines become an extremely rare issue.

I don't want to see us lose potential Python developers because we start 
requesting patches redone due to a ':' or ')' being the 80th character.


Amar.