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 -- https://mail.python.org/mailman/listinfo/python-list