What to use for finding as many syntax errors as possible.

[dn]

On 09/10/2022 23.09, Antoon Pardon wrote:
> I would like a tool that tries to find as many syntax errors as possible 
> in a python file. I know there is the risk of false positives when a 
> tool tries to recover from a syntax error and proceeds but I would 
> prefer that over the current python strategy of quiting after the first 
> syntax error. I just want a tool for syntax errors. No style 
> enforcements. Any recommandations? -- Antoon Pardon


Am not sure if have really understood problem being addressed, because 
it seems 'answered' - perhaps the question says more about the tool-set 
being utilised...


As someone who used to manually check and re-check code before 
submitting (first punched-cards, and later edited files) source to a 
compiler, it took some re-education to learn what to expect from a 
modern/language-intelligent IDE.

The topic was a major interest back in the days of batch-compilers. Plus 
we had other tools, eg CREF/XREF utilities which produced 
cross-references of identifier usage - and illustrated typos in 
identifiers, usage before value-assignment, etc (per request from one 
respondent).


Using an IDE which is inspecting source-code as it is being typed (or 
when an existing file is opened) will suggest what might?should be typed 
'next' (a mixed blessing IMHO!), and secondly highlights errors until 
they are noticed and dealt-with. Some, especially warnings, can be 
safely ignored - and yes, some are spurious and SHOULD be ignored!.

PyCharm* displays a number of indicators. The least intrusive appears in 
the top-right corner of the editor-tab listing, eg 8 errors, 2 warnings. 
So, apparently not 'stopping' at first error found.

Within the source-code itself, there are high-lights and under-lines (in 
and amongst the syntax highlighting presentation/theme) - which I 
suppose are easier to notice during data-entry if one is a touch-typist. 
Accordingly, not much of a context for multiple errors to be committed 
during a single coding-session, but remaining un-noticed until 'the end'.


For illustration, I took a simple tutorial* routine and deliberately 
introduced some/many of the types of error discussed within this thread. 
It would have been ideal to attach a graphic but here are some lines of 
code, under which I have attempted to represent a highlighted character 
(related to the line above) with an "H", and a (red) under-lined token 
with a "U". So, this is a feeble-attempt to show how the source is 
displayed and annotated by the IDE:

# mis-type the tuple-assignment by adding semi-colon
# which might also confuse Python into thinking of a second instruction
17     i, j = 0;, 1
               H  UH

# replace under-line/under-score with space: s/b expected_value
25     for expected value, fibonacci_number in \
            HHHHHHHHUUUUUU  UUUUUUUUUUUUUUUU

# mis-type the name of the zip built-in function
26         z ip( SERIES, fibonacci_generator() ):
            U UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU

# add an extra character within identifier, as if 'new' identifier
28      assert expected_value == fyibonacci_number
                UUUUUUUUUUUUUU    UUUUUUUUUUUUUUUUU

# these all trivial SYNTAX errors - could have tried leaving-out a 
keyword, but ...


Assuming the problem is not noticed/handled as the text is being typed, 
and in addition to the coder reviewing the work, recognising problems, 
and dealing with them him-/her-self; the IDE offers two follow-up 
mechanisms:

1 a means to jump 'focus' from the site of one error to the next, 
whereupon a pop-up will describe the error, eg (line 28) "Unresolved 
reference 'expected_value'"; which illustrates one problem in-isolation. 
In this case, line 28 is 'at fault' despite the fact that the 'error' is 
a consequence of THE problem on line 25!

2 a "Problems" Tool Window can be displayed, which will list every error 
and warning, with pretty, colored, icons, and the same message per 
example above, together with the relevant line-number, (the first two 
entries, as-listed, are 'warnings', and the rest are described as "errors"):

Need more values to unpack:17
Statement seems to have no effect:17
# so it has picked-up both of my nefarious intentions

Statement expected, found Py:COMMA:17
# as above
# NB the "Py:COMMA" is from tokenize (per @Chris contribution(s))
'in' expected:25
# logical, but confused by the space
Unresolved reference 'value':25
# pretty-much had no chance with so many faults in one statement!
Unresolved reference 'fibonacci_number':25
# ditto
Unresolved reference 'z':26
# absolutely!
':' expected:26
# evidently re-started after the "in" and did what it could with the "z"
Unresolved reference 'expected_value':28
# it would be "resolved" but for the first error on line 25
Unresolved reference 'fyibonacci_number':28
# ahah! Apparently trying to use an identifier before declaring/defining
# in reality, just another typo
# that said, I created the issue by inserting the "y"
# if I'd mistyped the entire identifier upon first-entry,
# the IDE's code-completion facility would have given choices and 'saved me'

NB the content displayed in the Problems Tool Window is dynamic. 
Accordingly, because of the way Python works, if one 'fixes' errors in 
line-number sequence, closing an error 'higher up' may well cause 
a(nother) error 'lower down' to disappear - thus reducing the number of 
spurious errors one is likely to encounter as a limitation of the 
automated code-evaluation!
-- 
Regards,
=dn