Op 9/10/2022 om 21:18 schreef Avi Gross:
Antoon, it may also relate to an interpreter versus compiler issue. Something like a compiler for C does not do anything except write code in an assembly language. It can choose to keep going after an error and start looking some more from a less stable place. Interpreters for Python have to catch interrupts as they go and often run code in small batches. Continuing to evaluate after an error could cause weird effects. So what you want is closer to a lint program that does not run code at all, or merely writes pseudocode to a file to be run faster later.
I just want a parser that doesn't give up on encoutering the first syntax error. Maybe do some semantic checking like checking the number of parameters.
I will say that often enough a program could report more possible errors. Putting your code into multiple files and modules may mean you could cleanly evaluate the code and return multiple errors from many modules as long as they are distinct. Finding all errors is not possible if recovery from one is not guaranteed.
I don't need it to find all errors. As long as it reasonably accuratly finds a significant number of them.
Is it that onerous to fix one thing and run it again? It was once when you handed in punch cards and waited a day or on very busy machines.
Yes I find it onerous, especially since I have a pipeline with unit tests and other tools that all have to redo their work each time a bug is corrected. -- Antoon. -- https://mail.python.org/mailman/listinfo/python-list
