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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
