[Python-Dev] Better SyntaxError messages
Fri, 7 Jul 2000 02:34:09 +0200 (CEST)
Ka-Ping Yee wrote:
> > [Ping]
> > > 4. Added int *expected_ret argument to PyParser_AddToken; on
> > > a syntax error, PyParser_AddToken (in parser.c) places the
> > > expected token type (if any) into this output parameter.
> > I'd suggest passing a pointer to the perrdetail structure (to the
> > whole error, that is), instead of a pointer to one of its fields.
> I did consider that; the reason i eventually decided against it
> is that munging perrdetail appears to be [parsetok.c] parsetok()'s
> responsibility, not [parser.c] PyParser_AddToken()'s. The latter
> doesn't mess with any of the other fields of perrdetail -- and it
> returns an error code which becomes err_ret->error, so passing in
> perrdetail gives PyParser_AddToken() two ways of returning the same
> information. The redundancy and possible future confusion didn't
> seem worth it.
> Another alternative is to change the return value so it *isn't*
> an error code (only a success/fail flag) and then rely on the error
> code in err_ret->error. I guess if you see a compelling reason for
> this i don't mind doing it. But is there one?
Okay. Since you've already altered the error list in errcode.h,
I think that the best thing to do is to re-introduce E_INDENT
but for the "missing indentation" case (reported to the user as
"expected an indented block"), then return E_INDENT from AddToken()
and revert back its signature. Thus all additional error cases you've
detected so far would be handled fine in pythonrun.c.
Does this sound good for you? I share most of your thoughts --
after another look at the updated patch, I don't think I like the
augmented perrdetail and the redundant communication interface with
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252