I will say that those of us meaning me, who express reservations are not arguing it is a bad idea to get more info in one sweep. Many errors come in bunches.
If I keep calling some function with the wrong number or type of arguments, it may be the same in a dozen places in my code. The first error report may make me search for the others places so I fix it all at once. Telling me where some instances are might speed that a bit. As long as it is understood that further errors are a heuristic and possibly misleading, fine. But an error like setting the size of a fixed length data structure to the right size may result in oodles of errors about being out of range that magically get fixed by one change. Sometimes too much info just gives you a headache. But a tool like you described could have uses even if imperfect. If you are teaching a course and students submit programs, could you grade the one with a single error higher than one with 5 errors shown imperfectly and fail the one with 600? On Sun, Oct 9, 2022, 1:53 PM Antoon Pardon <antoon.par...@vub.be> wrote: > > > Op 9/10/2022 om 19:23 schreef Karsten Hilbert: > > Am Sun, Oct 09, 2022 at 06:59:36PM +0200 schrieb Antoon Pardon: > > > >> Op 9/10/2022 om 17:49 schreef Avi Gross: > >>> My guess is that finding 100 errors might turn out to be misleading. > If you > >>> fix just the first, many others would go away. > >> At this moment I would prefer a tool that reported 100 errors, which > would > >> allow me to easily correct 10 real errors, over the python strategy > which quits > >> after having found one syntax error. > > But the point is: you can't (there is no way to) be sure the > > 9+ errors really are errors. > > > > Unless you further constrict what sorts of errors you are > > looking for and what margin of error or leeway for false > > positives you want to allow. > > Look when I was at the university we had to program in Pascal and > the compilor we used continued parsing until the end. Sure there > were times that after a number of reported errors the number of > false positives became so high it was useless trying to find the > remaining true ones, but it still was more efficient to correct the > obvious ones, than to only correct the first one. > > I don't need to be sure. Even the occasional wrong correction > is probably still more efficient than quiting after the first > syntax error. > > -- > Antoon. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
