On Wednesday, June 13, 2018 at 1:44:49 PM UTC-4, Paul Moore wrote: > On 13 June 2018 at 17:35, T Berger <brg...@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 -- https://mail.python.org/mailman/listinfo/python-list
