[AstroPy] Capturing pyfits warnings

[Victoria G. Laidler]

In developing pysynphot, which is intended to provide both an interactive environment for synthetic photometry and a library for scripting or more detailed programming, I have a similar situation where there are certain operations that should generate warnings (so the user is aware of them and can decide to take different actions as a result) but not exceptions (so it doesn't halt processing). 

The decision I made for pysynphot was to add a "warnings" attribute to the pysynphot objects that are produced. This attribute is a dictionary with key:value pairs keyed by warning type with values that correspond to the message that was printed for the user. Thus it is available for later use by a script at whatever point makes sense -- which may not be the point at which the warning is generated.

I wonder whether this approach would be a) feasiable, and b) useful to the PyFITS community?

Vicki Laidler

---- Original message ----
>Date: Wed, 15 Sep 2010 11:17:32 -0400
>From: astropy-bounces at scipy.org (on behalf of Anne Archibald <aarchiba at physics.mcgill.ca>)
>Subject: Re: [AstroPy] Capturing pyfits warnings  
>To: "Bridgman, William T." <william.t.bridgman at nasa.gov>
>Cc: AstroPy <astropy at scipy.net>
>
>On 15 September 2010 10:26, Bridgman, William T.
><william.t.bridgman at nasa.gov> wrote:
>> try:
>>        fimg=pyfits.open(dfile)
>> except:
>>        whatever...
>>
>> header=fimg[0].header
>>
>> If warnings are warnings, this runs fine.
>>
>> If warnings are elevated to exceptions, the pyfits.open throws the
>> exception before loading fimg.  The fimg[0].header access fails.
>> Putting fimg[0].header access inside the try: block doesn't help
>> either (of course).
>>
>> Perhaps inside the except: block I could set warnings back from
>> exceptions to warnings and do pyfits.open again.  I don't know that
>> much about python innards, but this sounds like something that would
>> cause other weird (stack?) problems as I examine the 22,000+ FITS
>> files in our data area.
>
>This is probably the best way to handle it. That is, turn warnings
>into exceptions and open the file. If an exception gets raised, note
>the details, then turn warnings back into warnings (which you have to
>do anyway) and reopen the file.
>
>I don't think you have to worry about having many exceptions mess up
>your stack; they are a fundamental part of python, not a an
>afterthought (e.g. setjmp()) and proper cleanup after exceptions is a
>basic requirement for extensions. There's plenty of code that uses an
>exception as the signal to terminate a loop, for example.
>
>In this particular context, it should be fairly efficient, since (I
>think) the open detects the problem while reading the header rather
>than while reading the (potentially very large) body of the FITS file.
>The main problem with this re-opening idea is that you only get
>information about the *first* warning emitted. If there are
>potentially more than one for a given file, you're going to have to do
>some grotesque monkeypatching.
>
>Anne
>
>> Tom
>>
>>
>> On Sep 15, 2010, at 10:06 AM, jtaylor2 at stsci.edu wrote:
>>
>>> Tom,
>>>
>>>   I am not sure I understand exactly what is going on here, but if
>>> having the warnings module issue exceptions instead of warnings is
>>> causing another warning to be raised as an exception that you would
>>> like to remain as a warning, you can fix this by using
>>> filterwarnings and supplying a regular expression that matches just
>>> the warning that you want raised as an exception.  In your case
>>> something like:
>>>
>>> warnings.filterwarnings('error',message='.*Warning:  File may have
>>> been.*"')
>>>
>>>   If you contact me directly at jtaylor2 at stsci.edu with more
>>> details, especially if you can point me to a fits file that is
>>> causing the problem, I may be able to be of more help.
>>>
>>>     Jim T.
>>
>> --
>> Dr. William T."Tom" Bridgman               Scientific Visualization
>> Studio
>> Global Science & Technology, Inc.          NASA/Goddard Space Flight
>> Center
>> Email: William.T.Bridgman at nasa.gov         Code 610.3
>> Phone: 301-286-1346                        Greenbelt, MD 20771
>> FAX:   301-286-1634                        http://svs.gsfc.nasa.gov/
>>
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>_______________________________________________
>AstroPy mailing list
>AstroPy at scipy.org
>http://mail.scipy.org/mailman/listinfo/astropy