PEP8 compliance

[Paul Moore]

On 13 June 2018 at 17:35, T Berger <brgrt2 at gmail.com> wrote:

> I did make the changes in IDLE, but I thought I must be in the wrong place. The line of code I got in terminal was:
> /Users/TamaraB/Desktop/mymodules/vsearch.py:1:25: E231 missing whitespace after ':'
> def search4vowels(phrase:str)->set:
>
> I thought the 1:25: E231 couldn't be referring to anything in my text editor. But now I see that 1:25 refers to the first line, 25th spot (I suppose the 25 refers to the spot BEFORE which I'm supposed to add white space. I don't know what the E231 refers to, but it doesn't seem helpful.

That's the correct interpretation of that message. Well done (and I
don't mean that patronisingly) - messages from tools like whatever it
was that reported these errors to you are often rooted in assumptions
which are *far* from obvious to someone new to programming.

To expand a little:

The 1 is as you say the line on which the tool spotted the problem.
Program text is viewed (by tools just as by people) as a block of
lines of text, numbered starting from line 1. Tools will number blank
lines (lines with nothing on them) equally with lines with text on
them - sometimes people number only the non-blank lines, but
programming tools don't typically do that.

The 25 does refer to the position on the line that the tool is
referring to. Position is measured in characters. You say "spot", and
that's as good a term as any. Characters as counted by a computer
include letters, numbers, punctuation, and even spaces. You can think
of it as "column on the screen" in this case and not be far wrong.

The E231 is a code for the specific error that the tool found - so it
means "missing whitespace". The text of the message is all you need to
deal with, but having a unique, concise code can help, for example
when looking up information in the documentation or the source code of
the tool. It's very helpful to quote error numbers like this when
reporting problems or asking for help, as they are more precise (to
people who know how to interpret them) than the textual message. But
reporting the text as well is crucial, as it saves people having to
look up the code to know what you're talking about!

> And, no, I'm not going to make these picayune changes that actually make the code harder to read. Adding a white space between "phrase:" and "str" just splits apart a conceptual unit in a complicated line of code. I was just doing this exercise in my workbook.

That's a very good attitude. There *are* good reasons for many of the
style recommendations, and as you learn more you may be persuaded to
change your view, but style guides are all ultimately about making
your code "readable", and it sounds like you are already developing a
good sense of how you want to group and present your code. That's
something many programmers can take a long time (years, in some cases)
to develop, and a good sense of style is often (IMO) what separates
good programmers from mediocre/bad ones. Reading other people's code
is often a very good way to develop a sense of style, if you get the
chance to do so.

Paul