PEP8 compliance

[T Berger]

On Wednesday, June 13, 2018 at 1:44:49 PM UTC-4, Paul  Moore wrote:
> 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

Thanks, Paul, for your encouraging, informative reply

Tamara