I stand corrected Chris, and others, as I pay the sin tax. Yes, there are many kinds of errors that logically fall into different categories or phases of evaluation of a program and some can be determined by a more static analysis almost on a line by line (or "statement" or "expression", ...) basis and others need to sort of simulate some things and look back and forth to detect possible incompatibilities and yet others can only be detected at run time and likely way more categories depending on the language.
But when I run the Python interpreter on code, aren't many such phases done interleaved and at once as various segments of code are parsed and examined and perhaps compiled into block code and eventually executed? So is the OP asking for something other than a Python Interpreter that normally halts after some kind of error? Tools like a linter may indeed fit that mold. This may limit some of the objections of when an error makes it hard for the parser to find some recovery point to continue from as no code is being run and no harmful side effects happen by continuing just an analysis. Time to go read some books about modern ways to evaluate a language based on more mathematical rules including more precisely what is syntax versus ... Suggestions? -----Original Message----- From: Python-list <python-list-bounces+avi.e.gross=gmail....@python.org> On Behalf Of Chris Angelico Sent: Monday, October 10, 2022 10:42 PM To: python-list@python.org Subject: Re: What to use for finding as many syntax errors as possible. On Tue, 11 Oct 2022 at 13:10, <avi.e.gr...@gmail.com> wrote: > If the above is: > > Import grumpy as np > > Then what happens if the code tries to find a file named "grumpy" > somewhere and cannot locate it and this is considered a syntax error > rather than a run-time error for whatever reason? Can you continue > when all kinds of functionality is missing and code asking to make a > np.array([1,2,3]) clearly fails? That's not a syntax error. Syntax is VERY specific. It is an error in Python to attempt to add 1 to "one", it is an error to attempt to look up the upper() method on None, it is an error to try to use a local variable you haven't assigned to yet, and it is an error to open a file that doesn't exist. But not one of these is a *syntax* error. Syntax errors are detected at the parsing stage, before any code gets run. The vast majority of syntax errors are grammar errors, where the code doesn't align with the parseable text of a Python program. (Non-grammatical parsing errors include using a "nonlocal" statement with a name that isn't found in any surrounding scope, using "await" in a non-async function, and attempting to import braces from the future.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
