[AstroPy] Capturing pyfits warnings
Victoria G. Laidler
Wed Sep 15 10:58:07 CDT 2010
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?
---- Original message ----
>Date: Wed, 15 Sep 2010 11:17:32 -0400
>From: firstname.lastname@example.org (on behalf of Anne Archibald <email@example.com>)
>Subject: Re: [AstroPy] Capturing pyfits warnings
>To: "Bridgman, William T." <firstname.lastname@example.org>
>Cc: AstroPy <email@example.com>
>On 15 September 2010 10:26, Bridgman, William T.
>> 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 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.
>> On Sep 15, 2010, at 10:06 AM, firstname.lastname@example.org 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 email@example.com 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@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 mailing list
More information about the AstroPy