This fixes the problem.
--- ./lex.py.orig 2008-09-24 09:51:26.000000000 -0600
+++ ./lex.py 2008-09-24 09:52:32.000000000 -0600
@@ -281,6 +281,7 @@
# Create a token for return
tok = LexToken()
+ tok.lexer = self
tok.value = m.group()
tok.lineno = self.lineno
tok.lexpos = lexpos
@@ -305,7 +306,7 @@
# If token is processed by a function, call it
- tok.lexer = self # Set additional attributes
useful in token rules
+ # Set additional attributes useful in token rules
self.lexmatch = m
self.lexpos = lexpos
@@ -329,6 +330,7 @@
# No match, see if in literals
if lexdata[lexpos] in self.lexliterals:
tok = LexToken()
+ tok.lexer = self
tok.value = lexdata[lexpos]
tok.lineno = self.lineno
tok.type = tok.value
On Wed, Sep 24, 2008 at 7:57 AM, David Beazley <[EMAIL PROTECTED]> wrote:
>
> Nope. I'll have to look at it in more detail to know why anything would be
> happening with this attribute---especially since in most rules, the exact
> same 'p' instance is used for
> everything. Hmmm. Curious.
>
> Cheers,
> Dave
>
> On Tue 23/09/08 5:40 PM , "Bart Whiteley" [EMAIL PROTECTED] sent:
>>
>>
>> I'm using ply-2.5.
>>
>>
>>
>> I have defined a p_error(p) function. For some parse errors, p (a
>>
>> LexToken) has a 'lexer' attribute. For other parse errors, p (still a
>>
>> LexToken) does not have a 'lexer' attribute. If I set a break point
>>
>> with pdb within p_error(), the stack traces look the same for both
>>
>> types of parse errors.
>>
>>
>>
>> Any idea why the LexToken argument to p_error() would lack the 'lexer'
>>
>> attribute at times?
>>
>>
>>
>> >>
>>
>>
>>
>>
>>
>
>
>
>
--~--~---------~--~----~------------~-------~--~----~
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 this group at
http://groups.google.com/group/ply-hack?hl=en
-~----------~----~----~----~------~----~------~--~---
