Step-by-step exec

[gregory.lielens at gmail.com]

On Nov 6, 1:02 pm, "saju.pil... at gmail.com" <saju.pil... at gmail.com>
wrote:
> On Nov 6, 4:27 pm, gregory.liel... at gmail.com wrote:
>
>
>
> > Hi,
>
> > I am using a small python file as an input file (defining constants,
> > parameters, input data, ...) for a python application.
> > The input file is simply read by an exec statement in a specific
> > dictionary, and then the application retrieve all the data it need
> > from the dictionary...
> > Everything is working nicely, but I'd like to have something a little
> > bit more robust regarding input file errors: now
> > any error in the python input script raise an exception and stop the
> > execution.
> > What I am trying to do is to execute it "step-by-step", so that I can
> > capture the exception if one line (or multi-line statement) fails,
> > print a warning about the failure, and continue the execution fo the
> > following lines/statements. Of course, an error on one line can
> > trigger errors in the following lines, but it does not matter in the
> > application I have in mind, the goal is to parse as much of the input
> > script as possible, warn about the errors, and check what's inside the
> > dictionary after the exec.
> > One way to do it is to read the input script line per line, and exec
> > each line in turn. However, this is not convenient as it does not
> > allow multi-line statements, or basic control flow like if - else
> > statements or loops.
>
> Do you have control over the input file generation ? If the input file
> can be easily divided into self sufficient blocks of code, you could
> read each block in one at a time and do a compile() and exec(). Your
> input file need not be a full python script too, you could just have
> token delimited blocks of python code which are read in 1 block at a
> time and then exec().
>
> -srp
>
>
>
> > Is there a better way for a step-by-step exec? Syntax errors in the
> > input script are not really a problem (as it is generated elsewhere,
> > it is not directly edited by users), although it would be nice to
> > catch. The biggest problem are runtime errors (attribute error, value
> > error, ...). Maybe compiling the file into a code object, and
> > executing this code object step-by-step in a way similar to debug? pdb
> > module should do something similar....
>
> > Best regards,
>
> > Greg.
>
>
Thanks for your input!
I had a similar solution in mind (with continuation comments to be
able to read multi-line statements, instead of statement delimiters,
but
I think your delimiter idea would be easier to implement).
The only problem is that files generated by current and older version
of the input generator (which do not have any kind of statement
delimiter)
will not be readable, or, if we just consider old file as one big
statement, will not offer the step-by-step execution. It would work
nice with new files,
but the best solution would be something that work also with older
auto-generated files...

In fact, the error in the input script are mainly caused by version
mismatch, and the step-by-step approach is
mainly for improving backward compatibility.
Having better backward compatibility starting from now on would be
nice, but having backward compatibility with previous versions would
be even better ;-)
contains multi-line statements