On 14/02/2021 02:23, Christopher Barker wrote:
Thanks Rob.
You've broken a number of "rules" code code formatting there ;-)
Thanks for the quotation marks. Indeed, PEP 8 provides guidelines, not
diktats.
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.
It's written to suit my editor. I'm with Brendan: restricting the whole
world to 80 chars per line is like insisting the whole world program in
COBOL.
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 :-)
Yes IMHO it would be a slight improvement. But AFAIU pattern matching
is not available yet.
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 ...
I cannot imagine how a dictionary, much less a subclass (of what)? could
have any relevance here. I'd be interested if you could elucidate.
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()
I'm well aware that if you apply PEP 8 guidelines strictly it would look
like the above. But is this supposed to be an improvement? My original
was a clear, tabular layout making the code structure completely clear,
the vertical alignment *highlighting where different cases are treated
differently and where they are treated similarly*. This is just an
amorphous mass of code that I find much harder to grok. (YMMV but I find
it hard to imagine.)
Rules are all very well, but "A Foolish Consistency is the Hobgoblin of
Little Minds" [PEP 8]
Best wishes
Rob
PS Can anyone shed any light on why Alt-R doesn't always "work" on
Windows 10? I believe there's some bit of installed software that has
hijacked it, but I'm not sure what.
On Fri, Feb 12, 2021 at 1:46 AM Rob Cliffe via Python-ideas
<python-ideas@python.org <mailto: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
<mailto:python-ideas@python.org>
To unsubscribe send an email to python-ideas-le...@python.org
<mailto:python-ideas-le...@python.org>
https://mail.python.org/mailman3/lists/python-ideas.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/
<https://mail.python.org/archives/list/python-ideas@python.org/message/JSCI223RQWSOABLTQ7OKEBQMOHJGUXBO/>
Code of Conduct: http://python.org/psf/codeofconduct/
<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/MPY27UVUWR5HRDFOVC7DN6VH46KEELVP/
Code of Conduct: http://python.org/psf/codeofconduct/
