[AstroPy] Capturing pyfits warnings
Bridgman, William T.
william.t.bridgman at nasa.gov
Wed Sep 15 12:39:39 EDT 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
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 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:
>>> If warnings are warnings, this runs fine.
>>> If warnings are elevated to exceptions, the pyfits.open throws the
>>> exception before loading fimg. The fimg.header access fails.
>>> Putting fimg.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
>> 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
>> some grotesque monkeypatching.
>>> On Sep 15, 2010, at 10:06 AM, jtaylor2 at stsci.edu wrote:
>>>> 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
>>>> 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
>>> Global Science & Technology, Inc. NASA/Goddard Space Flight
>>> 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
>> AstroPy mailing list
>> AstroPy at scipy.org
> AstroPy mailing list
> AstroPy at scipy.org
Dr. William T."Tom" Bridgman Scientific Visualization
Global Science & Technology, Inc. NASA/Goddard Space Flight
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/
More information about the AstroPy