[Python-Dev] Better SyntaxError messages

[Vladimir Marangozov]

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.
>
> [me]
> > 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.
>
[Ping]
> 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
PyParser_AddToken().

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252