How to debug TypeError: required field "lineno" missing from expr?

Mark Lawrence breamoreboy at yahoo.co.uk
Wed Jul 1 01:01:01 CEST 2015


On 29/06/2015 03:44, Steven D'Aprano wrote:
> On Mon, 29 Jun 2015 11:14 am, Mark Lawrence wrote:
>
>> Purely as an exercise I've been converting Grant Jenks' pypatt[1] from
>> 2.7 to 3.4.  I've managed to sort out most of the required changes by
>> checking on what I can see with an AST pretty printer[2].  So it's
>> rather frustrating to have the compile stage throw the error given in
>> the subject line.
>
> Now now Mark, you know how this works. Where's your COPY and PASTED
> traceback? Where's the Short, Self Contained, Correct Example?
>
> http://sscce.org/
>
> Our crystal ball is in no better state than yours :-)

The traceback was effectively that in the subject line.  I'd have 
provided a SSCCE if I'd had the faintest idea of how to produce one, 
which I didn't have a couple of days ago.

>
>
>> The code has a call to the ast fix_missing_locations function.  I'm
>> aware of the Armin Ronacher tweet[3] stating
>>
>> <quote>
>> "TypeError: required field "lineno" missing from stmt" — no, what you
>> actually mean is "tuple is not a statement'.
>> </quote>
>>
>> but I don't think this is the problem.
>
> That's what I dislike about Twitter. There's no context, and no way to tell
> what Armin is talking about. I've never seen this error, and cannot imagine
> how to get it, or what he means by "tuple is not a statement" for that
> matter. A tuple can be a statement:
>
> if condition:
>      (1, 2)  # Construct a tuple, then throw it away.
>
>
>> Still I've clearly managed to
>> screw something up somewhere along so line, so any bright ideas as to
>> how I can proceed?
>>
>> Further would it be worth raising an enhancement request to get some
>> better diagnostics from the built-in compile function,
>
> If you think it is worth waiting months or years before you can actually use
> those enhanced diagnostics, sure. What sort of diagnostics?
>
> Peering into my crystal ball, I see that you're maybe generating some code
> dynamically, then running something like:
>
>      code = compile(the_text, something, something)
>
> and that's giving you an error. What happens if you do this?
>
>      print(the_text)
>      code = compile(the_text, something, something)
>
>
> Can you extract the offending line that way? What happens if you copy and
> paste the_text into a Python file, and then try to import or run that file?
>

I managed to find the problem with the aid of 
https://github.com/simonpercivall/astunparse which allowed me to compare 
the 2.7 output  with the 3.4 and pinpoint precisely where I'd gone wrong.

Thanks anyway for your reply and all the others, it certainly got my 
brain engaged in a logical manner.  I might not be an expert on Python 
ASTs but I've certainly enjoyed playing with them.  All I've got to do 
now is correct the next problem in the pipeline.  Maybe I'll bore you 
all with that tomorrow :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence



More information about the Python-list mailing list