Why not make it take **kwargs rather than error_info_dict? That way it can
easily be extended while allowing people to ignore arguments they don't
care about.

On Tue, Oct 30, 2012 at 7:34 AM, David Beazley <[email protected]> wrote:

> I like the idea of having an p_error_verbose() function.     That's
> definitely doable.  I'll work on it.
>
> Cheers,
> Dave
>
>
> ----- Original Message -----
> From:
> [email protected]
>
> To:
> <[email protected]>
> Cc:
> "David Beazley" <[email protected]>
> Sent:
> Tue, 30 Oct 2012 04:09:54 -0700 (PDT)
> Subject:
> Re: p_error parameters lack information
>
>
>
> I think that's a great idea.
>
> I would not add an argument to p_error, because that would break
> backwards-compatibility.
> Perhaps you could add a new method with extended information. Like
> p_error_verbose(p, actions, state, stack)
>
> (or if you wish to allow more information in the future,
> p_error_verbose(p, error_info_dict) )
>
>
> On Tuesday, October 30, 2012 12:56:38 AM UTC+2, David Beazley wrote:
>
>> In the GIT repository for PLY, I refactored a bit of the error handling
>> code to simplify a few things, but I think I could be convinced to expand
>> it a bit more.    Let me think about how I would handle it.   Perhaps
>> p_error() handling could be expanded to support an optional second argument
>> in which the parser instance would be passed.   Certainly open to design
>> ideas on this.
>>
>> Cheers,
>> Dave
>>
>>
>> ----- Original Message -----
>> From:
>> [email protected]
>>
>> To:
>> <[email protected]>
>> Cc:
>>
>> Sent:
>> Sun, 28 Oct 2012 19:15:14 -0700 (PDT)
>> Subject:
>> p_error parameters lack information
>>
>>
>> One can define a p_error function to handle syntax errors, but
>> unfortunately, Ply provides no useful information to the function. I've
>> had
>> to resort to an ugly reflection hack just to provide meaningful error
>> messages. Would it be possible to improve the interface so that Ply
>> actually provides access to this information?
>>
>> def p_error(p):
>>     if p is None:
>>         print "Syntax error: unexpected EOF"
>>     else:
>>         print "Syntax error at line {}: unexpected token
>> {}".format(p.lineno, p.value)
>>
>>     #Ugly hack since Ply doesn't provide any useful error information
>>     import inspect
>>     frame = inspect.currentframe()
>>     cvars = frame.f_back.f_locals
>>     print 'Expected:', ', '.join(cvars['actions'][cvars[
>> 'state']].keys())
>>     print 'Found:', cvars['ltype']
>>     print 'Current stack:', cvars['symstack']
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ply-hack" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to ply-hack+
>> [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/ply-hack/-/lohTjGaPdqgJ.
>> For more options, visit 
>> https://groups.googlecom/groups/opt_out<https://groups.google.com/groups/opt_out>
>> .
>>
>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "ply-hack" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msg/ply-hack/-/noXUP4KKaOgJ.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "ply-hack" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"ply-hack" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to