atexit handlers - getting the return code

Mike Hull mikehulluk at googlemail.com
Tue Sep 27 15:12:09 EDT 2011


On Sep 27, 4:59 pm, Robert Kern <robert.k... at gmail.com> wrote:
> On 9/27/11 9:37 AM, Mike Hull wrote:
>
>
>
>
>
>
>
>
>
> > Hi Giampaolo,
> > Sorry, I didn't explain very clearly.
> > I have a python file, 'simulation_logger.py', (given below).
> > Then, in my scripts, I add the following lines to the top,
>
> > #simulation1.py:
> > ###################
> > from simulation_logger  import SimulationDecorator
> > SimulationDecorator.Init()
>
> > # Rest of the simulation script....
>
> > #####################
>
> > and at the end of the simulation, it should write the stdout/stderr,
> > the return code and any top level exception details into a database.
> > This is working except I can't work out how to get the return code
> > the script is going to return.
>
> I don't think that's available inside the process. You may want to use a
> "runner" script that records this information. Additionally, the runner script
> could record the stdout/stderr information more cleanly than stubbing out
> sys.stdout/sys.stderr. For example, if you have C or Fortran modules that use
> their own mechanisms to print things directly to the STDOUT/STDERR file
> descriptors, your sys.stdout/sys.stderr stubs will never be informed about it.
> However, if the runner script directs stdout/stderr to a pipe, it can read every
> bit of text that gets printed. Timing is probably also best recorded by the
> runner script to record the startup overhead of the Python interpreter. Continue
> to use the SimulationDecorator to record the traceback information, though.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless enigma
>   that is made terrible by our own mad attempt to interpret it as though it had
>   an underlying truth."
>    -- Umberto Eco

Hi Robert,
Thanks for this. The return code is not super important at this stage,
but I thought I would
try and get everything working neatly. Creating a separate runner
script is probably the way
to go. If i get some time I will implement it like that. My reason for
wanting to do it 'in
the same script' was that I also have another library that intercepts
calls to matplotlib's show(),
so I could ultimately create a pdf containing the script with figures
interjected at the right place.
Anyway, I will have to think about that some more.

Thanks again!

Mike




More information about the Python-list mailing list