[AstroPy] Capturing pyfits warnings

Bridgman, William T. william.t.bridgman@nasa....
Wed Sep 15 11:39:39 CDT 2010


I rather like this solution.

One problem I found when using the exception handler is the code was  
significantly slower, especially when processing the full file set  
(and even that is a subset of the total).

The suggested solution of turning off warning trapping and then back  
does seem kludgy and the possibility of another warning (or error) is  
a problem.

Tom
On Sep 15, 2010, at 11:58 AM, Victoria G. Laidler wrote:

> 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@scipy.org (on behalf of Anne Archibald <aarchiba@physics.mcgill.ca 
>> >)
>> Subject: Re: [AstroPy] Capturing pyfits warnings
>> To: "Bridgman, William T." <william.t.bridgman@nasa.gov>
>> Cc: AstroPy <astropy@scipy.net>
>>
>> On 15 September 2010 10:26, Bridgman, William T.
>> <william.t.bridgman@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@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@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@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@scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy@scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
> _______________________________________________
> AstroPy mailing list
> AstroPy@scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy

--
Dr. William T."Tom" Bridgman               Scientific Visualization  
Studio
Global Science & Technology, Inc.          NASA/Goddard Space Flight  
Center
Email: William.T.Bridgman@nasa.gov         Code 610.3
Phone: 301-286-1346                        Greenbelt, MD 20771
FAX:   301-286-1634                        http://svs.gsfc.nasa.gov/






More information about the AstroPy mailing list