f*cking re module

[Mike Meyer]

Rocco Moretti <roccomoretti at hotpop.com> writes:
> François Pinard wrote:
> If your program had only minor errors, there was likely a good chance
> that the compiler might guess correctly, and your program would
> compile to what you wanted in the first place. If not, by continuing
> on, the compiler can flag additional errors later in your code,
> allowing you to fix those bugs sooner. (Instead of choking on the
> first one and refusing to continue.)
>
> Error-checking-by-compiling only "works" if you have cheap computing
> power you can run attended. (Can you imagine what TDD would be like if
> you had to wait 24+ hrs between code executions?)

Yeah, but how many modern compilers give up after only one error? Most
compilers will reset the parser to a known state, and keep on trying
to parse the input. The none state may be erronious, leading to bogus
errors - possibly lots of them! - but at least it keeps trying. They
don't have to try to do DWIM to do this; they just have to have a
reasonable way to reset.

I only know one compiler that punts after the first error. Even with
lots of cheap computing power, it's still very annoying.

Come to think of it, Python does this, doesn't it? For some reason,
that doesn't annoy me. Maybe because I don't think of it as a
edit/compile/run cycle, but as an edit/run cycle, and I expect those
stop after one errror.

     <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.