Python expects a whitespace before and after an arithmetic operator but complains about whitespace around =
Is this a general python rule or something which has been decided by Rhino developers?
Hmm, Iâm not seeing that, no line too long or whitespace messages here. Is this ScriptEditor in Rhino or the Python script component in GH?
Itâs in the Python script editor in Grasshopper.
(Just saying ⌠Iâm no more a Rhino user, Iâm retired 
)
pycodestyle should be about style conventions only.
It shouldnât prevent the code from running.
Still not seeing thatâŚ
Hereâs a script in a Grasshopper file:
python_whitespace.gh (4.6 KB)
Thatâs what I see.
Line 8 raises no problem when changed to a = 1 + 1
Line 10 font_style = 0 however is fixed by removing the whitespaces.
Iâve been looking at the reference here: 2. Lexical analysis â Python 3.12.0 documentation
I only see this:
For me all of these work without a problem message
a=1 + 1
a=1+1
a = 1+1
a = 1 + 1
Is there some sort of âgrammarâ checker that you turned on?
The rs.AddText() throws an error, but I donât think that is the complaint here.
RhinoCodePluginGH.Legacy.NotSupportedInGHException: This type of object is not supported in Grasshopper, so this Python script cannot create it. You might want to use âscriptcontext.doc = Rhino.RhinoDoc.ActiveDocâ to use the Rhino doc, instead? If you do, remember to restore it: âscriptcontext.doc = ghdocâ.
at Rhino.Runtime.Code.Languages.PythonNet.CPythonCode.Execute(RunContext context)
at Rhino.Runtime.Code.Code.ExecTry(RunContext context, IPlatformDocument& doc, Object& docState)
at Rhino.Runtime.Code.Code.Run(RunContext context)
Hi,
you are doing two different things and its a flaw that Python devs decided to use the equals operator for argument assignment.
See:
font = âArialâ initializes a variable.
some_func(some_number=42) specifies an argument
now consider:
font = âArialâ
write_text(font=âBahnschriftâ)
print(font)
What do you expect? Do you see why formatting might matter. In C#
string font = âArialâ;
WriteText(font:âBahnschriftâ) ;
Therfore it is good practice to align to Pythons Style conventions. A static analyser helps you with that!
1 Like
FWIW those warnings are generated by a linter. I believe you can turn them off.
This might help:
Edit: On a side note, the error messages might be improved. In this case, by raising a syntax error exception and providing more useful information ala the current GHPython component and IDLE (paging doctor @eirannejad):
1 Like
Static Analysing/Linting is something good. A restrictive linter like you see in Pycharm is really good. Because if you work within a team, then there is no endless talk about code styling and metrics. Just take it, no discussion anymore about personal preferences. I had endless talks about it in the less restrictive world of C#. And its tiring and annoying when everybody has a different opinion on almost anything . People who made a linter are usually quite experienced and decided because of good reasons
Iâm self taugth and I find I have difficulties understanding whatâs wrong or right. In this case I was mostly just confused that in one situation a space is expected but in another situation it raises an error? I think Iâll just put a whitespace before and after = or any operator.
The yellow triangle things are linting warnings, not errors. You can ignore them, the code will run just fine.
As pointed out by @AndersDeleuran , line 8 is invalid syntax. Donât mix the two issues (linting warnings vs code errors), donât get confused by them.
I would turn off the linter (diagnostics, also pointed out by @AndersDeleuran here Python whitespace confusion - #10 by AndersDeleuran ), and concentrate on learning the language first. Once understand well enough you can turn on linting, which helps you to adhere to some pythonic conventions.
3 Likes
I would disagree to disable a static analyser. Its a feature and not just about styling, it can also help you in preventing certain beginner pitfalls and even prevent you from not so obvious bugs.
Most of us are self-taught. This makes it even more important to agree on a minimum set of rules.
You can but you should not ignore warnings. At least you should only ignore a warning if you know what its about.
Lets imagine you are writing code, and you decide to yield a warning. This usually means something odd was detected, but if you know what you are doing, then ignore it. But obviously you donât understand it yet