Thanks Rob. You've broken a number of "rules" code code formatting there ;-)
A big one is aligning things vertically, which, as a rule, I like. but this example does really push things out away from each other, so I'm not so sure. I found that the original looked like heck when I first opened it in my editor -- once I made the window wide enough it was better, but still pretty stretched out. Just for fun, here it is after being run through Black (which I don't usually use ....) -- but I think it looks better that way. Also -- my first thought looking at that was that it could really benefit from the pattern matching :-) And my second thought was that there could be a whole other pattern used here -- I usually find long chained elifs can be better expressed as a dict selection, or subclassing, or ... But not seeing the rest of the application, maybe maybe not in this case. if ch == "B": self.ToggleBackgroundColour(event) elif ch == "C": self.ChangeCommonChars(event) return elif ch == "D" and len(Areas) > 1: self.DeleteArea(event) return elif ch == "F" and __debug__: self.Info(event) return elif ch == "I": self.ChangeImagesToScroll(event) return elif ch == "J" and self.NUMBER_OF_IMAGES == 1: self.ChangeJustification(event) return elif ch == "L": self.ToggleShowLabels(event) elif ch == "M" and MaxNumberOfImages > 1: self.ChangeNumberOfImages(event) elif ch == "N" and CanZapImage: self.Rename(event) elif ch == "R" and not (area.Dynamic | area.IsTour): self.ToggleRandom(event, 1) elif ch == "S": self.ToggleSets(event, 1) elif ch == "T": self.ChangeTimer(event) return elif ch == "U" and not (area.Dynamic | area.Random): self.ToggleIsTour(event, 1) elif ch == "V" and OnAnImage: self.WindowsPhotoViewer(event) return elif ch == "W": self.ToggleWrap(event, 1) elif ch == "Y" and not (area.Random | area.IsTour): self.ToggleDynamic(event, 1) elif ch == "Z" and CanZapImage: self.Zap(event) elif ch == "A" and not (area.Dynamic | area.IsTour): self.ToggleRandom(event, 1) # Alt-R doesn't always work for some reason, so we give Alt-A as an alternative else: event.Skip() On Fri, Feb 12, 2021 at 1:46 AM Rob Cliffe via Python-ideas < python-ideas@python.org> wrote: > > > On 08/02/2021 00:39, Brendan Barnwell wrote: > > On 2021-02-07 09:59, Christopher Barker wrote: > >> All that being said, it's not that big a deal, and I personally don't > >> try to limit to 80 chars per line anyway -- preferring 90 or 95 -- I > >> haven't used a VT100 in decades .... > > > > To be honest I find it kind of ridiculous that people are still > > worrying about line lengths in this day and age. It's especially > > strange that people will talk about how a proposed feature interacts > > with relatively sophisticated editor/IDE features like syntax > > highlighting and autocompletion, yet still have no problem working > > with editors that are woefully limited on a much more basic feature. > > It's called line wrapping. > > > > We as humans should not be concerned with how long LOGICAL lines > > are until and unless it actually impinges on our ability to comprehend > > them. The appearance of the VISUAL line should not enter into our > > decision-making because that's a matter for the editor displaying the > > code. There's no reason not have lines that are 200 or 300 or even > > 1000 characters long if you want to (for instance for a long string > > literal); it's the editor's job to take a semantically-motivated set > > of lines and indentations and display them attractively. Then if > > different people have different preferences they can set their editors > > to different line widths and see the code in their preferred format. > > Editors that don't support such features need to be fixed and we > > shouldn't continue to enable them by insisting that people distort the > > semantic structure of their code to fit arbitrary guidelines like 80 > > or 95 characters. A person should insert a line break whenever they > > think it's a good idea for semantic reasons (e.g., separating > > statements) and not insert any when they don't think so, and leave the > > rest up to the editor. > > > +1. > Keeping lines to 80 characters makes it easier to understand *individual > lines*. > But allowing fewer, longer lines makes it easier to perceive *the code > structure as a whole*. > I want to illustrate this with a bit of actual code from one of my > programs. It uses lines up to 102 characters including 12-space > indentation. Oh, and it breaks another Python shibboleth - not having > multiple statements on one line. Apologies, it looks horrible in an > e-mail with the spacing all mucked up, so I have put it in an attachment > (a plain ASCII file). > IMHO this is a piece of well-written, self-documenting code that I would > find much harder to grok or look things up in if were laid out > differently. YMMV . In fact if it were laid out differently, I would > want to document it, and the documentation would be a table that looks > very much like the code "as is". > > Rob Cliffe > > > > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/JSCI223RQWSOABLTQ7OKEBQMOHJGUXBO/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/T2UVXLFJ3OUJDZTGLIJOLOYEQOGF53DC/ Code of Conduct: http://python.org/psf/codeofconduct/