From perry at stsci.edu Wed Sep 1 15:36:12 2010 From: perry at stsci.edu (Perry Greenfield) Date: Wed, 1 Sep 2010 15:36:12 -0400 Subject: [AstroPy] Developer Job Openings at Space Telescope Science Institute Message-ID: <63BE5DE9-4882-4B2E-B03A-F28349DB39C0@stsci.edu> We are advertising for two different positions at the Space Telescope Science Institute (located on the Johns Hopkins University Campus in Baltimore, Md). STScI is seeking Senior Systems Software Engineers to develop applications to calibrate and analyze data from the Hubble and the James Webb Space Telescopes. **************************************************************************** First position: Description The developer will work with other members of the Science Software Branch and instrument scientists to develop applications to calibrate and analyze data from the Hubble Space Telescope and its successor, the James Webb Space Telescope, as well as other astronomy-related projects. The individual will be developing open source applications primarily in Python and C, using open source tools developed at STScI, such as PyRAF and PyFITS, and elsewhere. Some projects may involve developing software applications or libraries as part of a team, or leading a team. Requirements Candidates should have experience writing applications to calibrate, reduce, and analyze scientific data, preferably astronomical data. A background in astronomy and experience with astronomical data reduction is highly desirable. Candidates should have experience writing large programs in a compiled language as well as experience with an interpreted language such as IDL, Matlab, or Python. Experience using array manipulations facilities such as are available in IDL, Matlab, numpy/numarray, or APL is a plus. Experience using software engineering tools such as debuggers, CVS or subversion, and bug trackers is strongly desired. Strong analytical, problem-solving, planning, and organizational skills are needed, and excellent written and verbal communication skills are essential. Prior experience in developing medium or large projects sufficient to demonstrate the specified knowledge, skills and abilities is required. Qualified candidates should possess a Bachelor's degree in a science- related field such as Physics, Astronomy, or Mathematics. A Master's or Ph.D degree is desirable. Substitution of additional relevant education or experience for the stated qualifications may be considered. Apply through the following link: https://www.ultirecruit.com/SPA1004/jobboard/JobDetails.aspx?__ID=*6D48E0EFCC47915A **************************************************************************** Second position: Description The developer will work with other members of the Science Software Branch to help in enhancing and maintaining our Python-based framework for developing astronomical data analysis and calibration applications. STScI has pioneered in the generation of tools for using Python for scientific analysis and programming through its development of PyRAF, numarray, PyFITS, and contributions to other Python Open Source projects. The individual being sought will help STScI maintain its leadership in this area by developing leading-edge capabilities by enhancing existing tools such as PyRAF and PyFITS, contributing to scipy, numpy, and matplotlib, and developing new libraries to meet the needs of future astronomical processing. Some projects may involve developing software tools as part of a team, or leading a team. Work will also require working with an external community on Open Source software projects. Requirements Candidates should be experienced with systems-level programming, preferably with C or C++ and familiar with variances in processor and operating system architectures (preferably Linux, OS X, and MS Windows) with regard to file systems, memory, data types and efficiency, as well as modern software development techniques including Object-Oriented design and programming. Experience with Python and writing C extensions for Python is highly desirable. A working knowledge of any of the following would be a plus: parsers, code generation, numerical techniques, image processing and data analysis, web and network protocols, or parallel processing. Experience using software engineering tools such as debuggers, version control systems (e.g., subversion), and bug trackers is strongly desired. Strong analytical, problem-solving, planning, and organizational skills are needed, and excellent written and verbal communication skills are essential. Prior experience in developing medium or large projects sufficient to demonstrate the specified knowledge, skills and abilities is required. Qualified candidates should possess a Bachelor's Degree in Computer Science, Physics, Math, or technically related field. Master's degree preferred. Substitution of additional relevant education or experience for the stated qualifications may be considered. Apply through the following link: https://www.ultirecruit.com/SPA1004/jobboard/JobDetails.aspx?__ID=*85D01A9E3BE42CFD **************************************************************************** STScI offers an excellent benefits package, tuition reimbursement, competitive salaries, and a stimulating work environment. Interested candidates are requested to complete an on-line application, attach a resume in the "Resume Upload Section." Please include job #10-0083 in the filename. Resumes received by October 15, 2010 will receive full consideration. Committed to the benefits of diversity, we strongly encourage qualified women and minority candidates to apply. EOE/AA/M/F/D/V. From astropython at gmail.com Thu Sep 2 09:08:52 2010 From: astropython at gmail.com (Astronomical Python) Date: Thu, 2 Sep 2010 09:08:52 -0400 Subject: [AstroPy] ATpy 0.9.4 Release Message-ID: We are pleased to announce the release of ATpy 0.9.4! ATpy is a high-level Python package providing a generic Table class that can contain data and meta-data, and includes column manipulation, row selection, and sorting methods. In addition, read and write methods are provided to to seamlessly read and write table data to a number of formats, building on existing Python modules. More information and links to download the latest version of ATpy can be found at http://atpy.sourceforge.net/ The main changes in this version are: - support for reading and writing HDF5 files via the h5py package, including support for reading/writing to groups. For more information, see http://atpy.sourceforge.net/format_hdf5.html - support for reading arbitrary ASCII tables via the asciitable package, which includes pre-defined formats such as Machine Readable Tables, RDB tables, and DAOPhot tables. For more information, see http://atpy.sourceforge.net/format_ascii.html - reading in of large FITS tables has been sped up by a factor of 10-20x - minor improvements and bug fixes We have now created two Google Groups - one for announcements: http://groups.google.com/group/atpy-announce and one for user discussion: http://groups.google.com/group/atpy-users The latter will now replace the ATpy forums. Bug reports and feature requests should be submitted to the Sourceforge trackers at: https://sourceforge.net/tracker/?group_id=259666 Please do not hesitate to let us know if you encounter any problems with this release, Cheers, Thomas Robitaille and Eli Bressert From oneaufs at gmail.com Fri Sep 3 05:06:46 2010 From: oneaufs at gmail.com (Prasanth) Date: Fri, 3 Sep 2010 14:36:46 +0530 Subject: [AstroPy] Python interface to TPM Message-ID: Hello, I have written a python interface to Jeff Percival's TPM library, using SWIG. See http://phn.github.com/pytpm/ for more details. There are some "doctests" in the file lib/utils.py. At this moment two of these fails. I was expecting to get a certain result from a couple of functions, but they don't give the answer I expect. The functions are utils.rdb2j() and rdb2jd(). I guess the reason is that I don't understand the "rdb" time, as defined in the TPM source files rdb2ymd.c and ymd2rdb.c. Help on this will be great. Thanks, Prasanth Nair From william.t.bridgman at nasa.gov Tue Sep 14 09:41:40 2010 From: william.t.bridgman at nasa.gov (Bridgman, William T.) Date: Tue, 14 Sep 2010 09:41:40 -0400 Subject: [AstroPy] Capturing pyfits warnings Message-ID: <6B465667-81D2-4C0B-AF45-4B5A25942ADC@nasa.gov> I'm trying to get an inventory of all the FITS files I'm storing locally, to track down duplicates and determine data gaps in covering certain phenomena. I'm getting a warning from pyfits about file size mismatches. Is there an elegant way to capture this message, or a warning code, that I can save with the file inventory record for generating a summary report? I see some items in the pyfits doc on capturing this with the warnings module but it seems more focussed on logging. It is unclear how I would capture the warning information as a separate variable to save with the inventory dictionary. Thanks, Tom -- 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/ From Jim.Vickroy at noaa.gov Tue Sep 14 10:24:58 2010 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue, 14 Sep 2010 08:24:58 -0600 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: <6B465667-81D2-4C0B-AF45-4B5A25942ADC@nasa.gov> References: <6B465667-81D2-4C0B-AF45-4B5A25942ADC@nasa.gov> Message-ID: <4C8F85BA.8070609@noaa.gov> Bridgman, William T. wrote: > I'm trying to get an inventory of all the FITS files I'm storing > locally, to track down duplicates and determine data gaps in covering > certain phenomena. > > I'm getting a warning from pyfits about file size mismatches. Is > there an elegant way to capture this message, or a warning code, that > I can save with the file inventory record for generating a summary > report? > > I see some items in the pyfits doc on capturing this with the warnings > module but it seems more focussed on logging. It is unclear how I > would capture the warning information as a separate variable to save > with the inventory dictionary. > > Thanks, > Tom > -- > 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 > Does this work for you? >>> import sys >>> sys.version '2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]' >>> import pyfits >>> pyfits.__version__ '2.2.2' >>> source = 'my.fit' >>> >>> try: ... HDUs = pyfits.open(source) ... except IOError as error: ... # do whatever you wish with the captured *error* ... ... print error.message ... print error.filename ... print error.errno ... print error.args ... print error.strerror ... finally: ... HDUs.close() ... Header missing END card. None None ('Header missing END card.',) None >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabricio at ferrari.pro.br Tue Sep 14 13:35:02 2010 From: fabricio at ferrari.pro.br (Fabricio Ferrari) Date: Tue, 14 Sep 2010 14:35:02 -0300 Subject: [AstroPy] Pyfits writeto w/ clobber Message-ID: Also regarding Pyfits, the new version 1.3 has a problem when one tries to pyfits.writeto() a file with the clobber=True argument. In the previous version the clobber worked fine, but now it complains when you try to overwrite a file. Does anyone have a similar problem? Some solution? thanks F ..-. ..-. Fabricio Ferrari? ? ?? [www.ferrari.pro.br] Universidade Federal do Pampa Bag? RS Brasil 2010/9/14 : > Send AstroPy mailing list submissions to > ? ? ? ?astropy at scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?http://mail.scipy.org/mailman/listinfo/astropy > or, via email, send a message with subject or body 'help' to > ? ? ? ?astropy-request at scipy.org > > You can reach the person managing the list at > ? ? ? ?astropy-owner at scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of AstroPy digest..." > > > Today's Topics: > > ? 1. Capturing pyfits warnings (Bridgman, William T.) > ? 2. Re: Capturing pyfits warnings (Jim Vickroy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 14 Sep 2010 09:41:40 -0400 > From: "Bridgman, William T." > Subject: [AstroPy] Capturing pyfits warnings > To: AstroPy > Message-ID: <6B465667-81D2-4C0B-AF45-4B5A25942ADC at nasa.gov> > Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes > > I'm trying to get an inventory of all the FITS files I'm storing > locally, to track down duplicates and determine data gaps in covering > certain phenomena. > > I'm getting a warning from pyfits about file size mismatches. ?Is > there an elegant way to capture this message, or a warning code, that > I can save with the file inventory record for generating a summary > report? > > I see some items in the pyfits doc on capturing this with the warnings > module but it seems more focussed on logging. ?It is unclear how I > would capture the warning information as a separate variable to save > with the inventory dictionary. > > Thanks, > Tom > -- > 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/ > > > > > > > ------------------------------ > > Message: 2 > Date: Tue, 14 Sep 2010 08:24:58 -0600 > From: Jim Vickroy > Subject: Re: [AstroPy] Capturing pyfits warnings > To: "Bridgman, William T." > Cc: AstroPy > Message-ID: <4C8F85BA.8070609 at noaa.gov> > Content-Type: text/plain; charset="iso-8859-1" > > Bridgman, William T. wrote: >> I'm trying to get an inventory of all the FITS files I'm storing >> locally, to track down duplicates and determine data gaps in covering >> certain phenomena. >> >> I'm getting a warning from pyfits about file size mismatches. ?Is >> there an elegant way to capture this message, or a warning code, that >> I can save with the file inventory record for generating a summary >> report? >> >> I see some items in the pyfits doc on capturing this with the warnings >> module but it seems more focussed on logging. ?It is unclear how I >> would capture the warning information as a separate variable to save >> with the inventory dictionary. >> >> Thanks, >> Tom >> -- >> 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 >> > Does this work for you? > > ?>>> import sys > ?>>> sys.version > '2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]' > ?>>> import pyfits > ?>>> pyfits.__version__ > '2.2.2' > ?>>> source = 'my.fit' > ?>>> > ?>>> try: > ... ? ? HDUs = pyfits.open(source) > ... except IOError as error: > ... ? ?# do whatever you wish with the captured *error* ... > ... ? ? print error.message > ... ? ? print error.filename > ... ? ? print error.errno > ... ? ? print error.args > ... ? ? print error.strerror > ... finally: > ... ? ? HDUs.close() > ... > Header missing END card. > None > None > ('Header missing END card.',) > None > ?>>> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://mail.scipy.org/pipermail/astropy/attachments/20100914/c96b0dc6/attachment-0001.html > > ------------------------------ > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > > End of AstroPy Digest, Vol 49, Issue 3 > ************************************** > From william.t.bridgman at nasa.gov Tue Sep 14 13:47:37 2010 From: william.t.bridgman at nasa.gov (Bridgman, William T.) Date: Tue, 14 Sep 2010 13:47:37 -0400 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: <4C8F85BA.8070609@noaa.gov> References: <6B465667-81D2-4C0B-AF45-4B5A25942ADC@nasa.gov> <4C8F85BA.8070609@noaa.gov> Message-ID: <4F750E06-CAA3-4DE6-8E39-787F3646133D@nasa.gov> I tried using the Exceptions & Warning class try: fimg=pyfits.open(dfile) except Warning as w: print w.filename, w.message finally: fimg.close() and it still doesn't grab it. I get the warning: Warning: File may have been truncated: actual file length (2102784) is smaller than the expected size (4213440) I've done limited work with the Exceptions class, and until now, nothing with the Warnings class so I'm probably missing something. Tom On Sep 14, 2010, at 10:24 AM, Jim Vickroy wrote: > --_000_4C8F85BA8070609noaagov_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Bridgman, William T. wrote: > > I'm trying to get an inventory of all the FITS files I'm storing > locally, to track down duplicates and determine data gaps in covering > certain phenomena. > > I'm getting a warning from pyfits about file size mismatches. Is > there an elegant way to capture this message, or a warning code, that > I can save with the file inventory record for generating a summary > report? > > I see some items in the pyfits doc on capturing this with the warnings > module but it seems more focussed on logging. It is unclear how I > would capture the warning information as a separate variable to save > with the inventory dictionary. > > Thanks, > Tom > -- > 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 > > > Does this work for you? > >>>> import sys >>>> sys.version > '2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit > (Intel)]' >>>> import pyfits >>>> pyfits.__version__ > '2.2.2' >>>> source =3D 'my.fit' >>>> >>>> try: > ... HDUs =3D pyfits.open(source) > ... except IOError as error: > ... # do whatever you wish with the captured *error* ... > ... print error.message > ... print error.filename > ... print error.errno > ... print error.args > ... print error.strerror > ... finally: > ... HDUs.close() > ... > Header missing END card. > None > None > ('Header missing END c -- 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/ From jturner at gemini.edu Tue Sep 14 14:09:36 2010 From: jturner at gemini.edu (James Turner) Date: Tue, 14 Sep 2010 14:09:36 -0400 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: <4F750E06-CAA3-4DE6-8E39-787F3646133D@nasa.gov> References: <6B465667-81D2-4C0B-AF45-4B5A25942ADC@nasa.gov> <4C8F85BA.8070609@noaa.gov> <4F750E06-CAA3-4DE6-8E39-787F3646133D@nasa.gov> Message-ID: <4C8FBA60.50103@gemini.edu> Hi Tom, > I've done limited work with the Exceptions class, and until now, > nothing with the Warnings class so I'm probably missing something. I'd try this: http://docs.python.org/library/warnings.html Cheers, James. From Jim.Vickroy at noaa.gov Tue Sep 14 14:12:20 2010 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue, 14 Sep 2010 12:12:20 -0600 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: <4F750E06-CAA3-4DE6-8E39-787F3646133D@nasa.gov> References: <6B465667-81D2-4C0B-AF45-4B5A25942ADC@nasa.gov> <4C8F85BA.8070609@noaa.gov> <4F750E06-CAA3-4DE6-8E39-787F3646133D@nasa.gov> Message-ID: <4C8FBB04.60506@noaa.gov> Bridgman, William T. wrote: > I tried using the Exceptions & Warning class > > try: > fimg=pyfits.open(dfile) > except Warning as w: > print w.filename, w.message > finally: > fimg.close() > > and it still doesn't grab it. I get the warning: > > Warning: File may have been truncated: actual file length (2102784) is > smaller than the expected size (4213440) > > I've done limited work with the Exceptions class, and until now, > nothing with the Warnings class so I'm probably missing something. > > Tom > Take a look at http://www.doughellmann.com/PyMOTW/warnings/ which discusses how to convert a warning to an exception. -- jv > On Sep 14, 2010, at 10:24 AM, Jim Vickroy wrote: > > >> --_000_4C8F85BA8070609noaagov_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> Bridgman, William T. wrote: >> >> I'm trying to get an inventory of all the FITS files I'm storing >> locally, to track down duplicates and determine data gaps in covering >> certain phenomena. >> >> I'm getting a warning from pyfits about file size mismatches. Is >> there an elegant way to capture this message, or a warning code, that >> I can save with the file inventory record for generating a summary >> report? >> >> I see some items in the pyfits doc on capturing this with the warnings >> module but it seems more focussed on logging. It is unclear how I >> would capture the warning information as a separate variable to save >> with the inventory dictionary. >> >> Thanks, >> Tom >> -- >> 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 >> >> >> Does this work for you? >> >> >>>>> import sys >>>>> sys.version >>>>> >> '2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit >> (Intel)]' >> >>>>> import pyfits >>>>> pyfits.__version__ >>>>> >> '2.2.2' >> >>>>> source =3D 'my.fit' >>>>> >>>>> try: >>>>> >> ... HDUs =3D pyfits.open(source) >> ... except IOError as error: >> ... # do whatever you wish with the captured *error* ... >> ... print error.message >> ... print error.filename >> ... print error.errno >> ... print error.args >> ... print error.strerror >> ... finally: >> ... HDUs.close() >> ... >> Header missing END card. >> None >> None >> ('Header missing END c >> > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtaylor2 at stsci.edu Tue Sep 14 15:00:23 2010 From: jtaylor2 at stsci.edu (jtaylor2 at stsci.edu) Date: Tue, 14 Sep 2010 15:00:23 -0400 (EDT) Subject: [AstroPy] Capturing pyfits warnings Message-ID: <20100914150023.ACH22403@comet.stsci.edu> Tom, Jim's suggestion should work as long as what is being generated is an exception and not a warning. If a warning is being generated through the warnings module, you will need to have the warning module generate an exception instead of a warning message. The PyFITS user manual gives an example of ignoring a warning message, but the same template applies to raising an exception. Just replace the word 'ignore' in the samples with the word 'error'. So when starting a python session use: python -W"error" Or when running a script: python -W"error" myscript.py Or within your script: import warnings import pyfits warnings.resetwarnings() warnings.filterwarnings('error', category=UserWarning, append=True) # do your thing. Then using Jim's try/except block should get these warnings as well. Jim T. From Jim.Vickroy at noaa.gov Tue Sep 14 15:43:10 2010 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue, 14 Sep 2010 13:43:10 -0600 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: <20100914150023.ACH22403@comet.stsci.edu> References: <20100914150023.ACH22403@comet.stsci.edu> Message-ID: <4C8FD04E.8060703@noaa.gov> Hi John, I'm curious to learn why pyfits uses the *warnings* module in this fashion. I naively would expect to see exceptions in the situation encountered by Tom. Thanks, -- jv jtaylor2 at stsci.edu wrote: > Tom, > > Jim's suggestion should work as long as what is being generated is an exception and not a warning. If a warning is being generated through the warnings module, you will need to have the warning module generate an exception instead of a warning message. The PyFITS user manual gives an example of ignoring a warning message, but the same template applies to raising an exception. Just replace the word 'ignore' in the samples with the word 'error'. > > So when starting a python session use: > > python -W"error" > > Or when running a script: > > python -W"error" myscript.py > > Or within your script: > > import warnings > import pyfits > > warnings.resetwarnings() > warnings.filterwarnings('error', category=UserWarning, append=True) > > # do your thing. > > > Then using Jim's try/except block should get these warnings as well. > > Jim T. > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From William.T.Bridgman at nasa.gov Tue Sep 14 16:16:25 2010 From: William.T.Bridgman at nasa.gov (Bridgman, William T.) Date: Tue, 14 Sep 2010 16:16:25 -0400 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: <4C8FD04E.8060703@noaa.gov> References: <20100914150023.ACH22403@comet.stsci.edu> <4C8FD04E.8060703@noaa.gov> Message-ID: <5BA058B3-2785-4393-A02C-7C9B66E79662@nasa.gov> I've got something almost working based on this prescription. In some ways, I think throwing an exception might not be the preferred behavior. Doesn't the actual FITS standard have some odd data block size (2880 bytes?). I suspect the messages are from files that are not quite filling the block but are not actually corrupted. I'm trying to track these errors/warnings to determine if that is indeed the case. Thanks, Tom On Sep 14, 2010, at 3:43 PM, Jim Vickroy wrote: > Hi John, > > I'm curious to learn why pyfits uses the *warnings* module in this > fashion. I naively would expect to see exceptions in the situation > encountered by Tom. > > Thanks, > -- jv > > jtaylor2 at stsci.edu wrote: >> Tom, >> >> Jim's suggestion should work as long as what is being generated >> is an exception and not a warning. If a warning is being generated >> through the warnings module, you will need to have the warning >> module generate an exception instead of a warning message. The >> PyFITS user manual gives an example of ignoring a warning message, >> but the same template applies to raising an exception. Just >> replace the word 'ignore' in the samples with the word 'error'. >> >> So when starting a python session use: >> >> python -W"error" >> >> Or when running a script: >> >> python -W"error" myscript.py >> >> Or within your script: >> >> import warnings >> import pyfits >> >> warnings.resetwarnings() >> warnings.filterwarnings('error', category=UserWarning, >> append=True) >> >> # do your thing. >> >> >> Then using Jim's try/except block should get these warnings as >> well. >> >> Jim T. >> >> >> >> _______________________________________________ >> 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 -- 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/ From Jim.Vickroy at noaa.gov Tue Sep 14 16:36:44 2010 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue, 14 Sep 2010 14:36:44 -0600 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: <5BA058B3-2785-4393-A02C-7C9B66E79662@nasa.gov> References: <20100914150023.ACH22403@comet.stsci.edu> <4C8FD04E.8060703@noaa.gov> <5BA058B3-2785-4393-A02C-7C9B66E79662@nasa.gov> Message-ID: <4C8FDCDC.3020905@noaa.gov> Bridgman, William T. wrote: > I've got something almost working based on this prescription. > > In some ways, I think throwing an exception might not be the preferred > behavior. > Why would that be the case? What is the preferred behavior? If I understood your original posting correctly, you were looking to handle an exception. I think that is the typical behavior in Python. -- jv > Doesn't the actual FITS standard have some odd data block size (2880 > bytes?). I suspect the messages are from files that are not quite > filling the block but are not actually corrupted. > > I'm trying to track these errors/warnings to determine if that is > indeed the case. > > Thanks, > Tom > On Sep 14, 2010, at 3:43 PM, Jim Vickroy wrote: > > >> Hi John, >> >> I'm curious to learn why pyfits uses the *warnings* module in this >> fashion. I naively would expect to see exceptions in the situation >> encountered by Tom. >> >> Thanks, >> -- jv >> >> jtaylor2 at stsci.edu wrote: >> >>> Tom, >>> >>> Jim's suggestion should work as long as what is being generated >>> is an exception and not a warning. If a warning is being generated >>> through the warnings module, you will need to have the warning >>> module generate an exception instead of a warning message. The >>> PyFITS user manual gives an example of ignoring a warning message, >>> but the same template applies to raising an exception. Just >>> replace the word 'ignore' in the samples with the word 'error'. >>> >>> So when starting a python session use: >>> >>> python -W"error" >>> >>> Or when running a script: >>> >>> python -W"error" myscript.py >>> >>> Or within your script: >>> >>> import warnings >>> import pyfits >>> >>> warnings.resetwarnings() >>> warnings.filterwarnings('error', category=UserWarning, >>> append=True) >>> >>> # do your thing. >>> >>> >>> Then using Jim's try/except block should get these warnings as >>> well. >>> >>> Jim T. >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hodge at stsci.edu Tue Sep 14 16:41:23 2010 From: hodge at stsci.edu (Phil Hodge) Date: Tue, 14 Sep 2010 16:41:23 -0400 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: <4C8FDCDC.3020905@noaa.gov> References: <20100914150023.ACH22403@comet.stsci.edu> <4C8FD04E.8060703@noaa.gov> <5BA058B3-2785-4393-A02C-7C9B66E79662@nasa.gov> <4C8FDCDC.3020905@noaa.gov> Message-ID: <4C8FDDF3.7070707@stsci.edu> > Why would that be the case? > What is the preferred behavior? If the problem was in fact that the file size was not an integral multiple of 2880, but the contents were not actually corrupted, one could copy the file to another and correct the problem simply by opening the file with pyfits and then using the writeto method. If you can't open the file with pyfits, you can't fix the problem using pyfits. Phil From aarchiba at physics.mcgill.ca Tue Sep 14 17:14:45 2010 From: aarchiba at physics.mcgill.ca (Anne Archibald) Date: Tue, 14 Sep 2010 17:14:45 -0400 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: <4C8FD04E.8060703@noaa.gov> References: <20100914150023.ACH22403@comet.stsci.edu> <4C8FD04E.8060703@noaa.gov> Message-ID: On 14 September 2010 15:43, Jim Vickroy wrote: > I'm curious to learn why pyfits uses the *warnings* module in this > fashion. I naively would expect to see exceptions in the situation > encountered by Tom. I get the same warning, about partial blocks at the end of a data file, all the time. If an exception were raised, I would not be able to process those files. What seems to happen is that these data files are produced by a pulsar backend streaming to disk; when an observing run is stopped, the writing to disk seems to stop partway through the block. But all the data up to that point is perfectly valid. In fact, even if the backend crashed and appended gibberish to the file I'd still want to work with all the valid data. So raising an exception is too forceful a way to signal a problem with the file. Anne From jtaylor2 at stsci.edu Tue Sep 14 17:22:17 2010 From: jtaylor2 at stsci.edu (jtaylor2 at stsci.edu) Date: Tue, 14 Sep 2010 17:22:17 -0400 (EDT) Subject: [AstroPy] Capturing pyfits warnings Message-ID: <20100914172217.ACH25938@comet.stsci.edu> Jim, A warning is generated so that when you have a corrupt file, you have a chance to still look at any HDU's that are not corrupt. Jim T. From jtaylor2 at stsci.edu Tue Sep 14 17:29:58 2010 From: jtaylor2 at stsci.edu (jtaylor2 at stsci.edu) Date: Tue, 14 Sep 2010 17:29:58 -0400 (EDT) Subject: [AstroPy] Capturing pyfits warnings Message-ID: <20100914172958.ACH26053@comet.stsci.edu> Tom, Based on the warning message you are getting, your file is indeed corrupt. The file size 2102784 is not a multiple of 2880 so their must be a problem with the file. Your problem may be the same as Anne has indicated or it may not. At any rate, the file you have is not fits complient. Although PyFITS may be able to handle the extensions in the file that are. Jim T. From jtaylor2 at stsci.edu Tue Sep 14 17:47:04 2010 From: jtaylor2 at stsci.edu (jtaylor2 at stsci.edu) Date: Tue, 14 Sep 2010 17:47:04 -0400 (EDT) Subject: [AstroPy] Pyfits writeto w/ clobber Message-ID: <20100914174704.ACH26323@comet.stsci.edu> Fabricio, I don't know about version 1.3 of pyfits which is several years old, but the current version is 2.3.1 and the clobber argument to pyfits.writeto() works correctly. You may get the latest version of pyfits from http://www.stsci.edu/resources/software_hardware/pyfits/Download. Jim T. From fabricio at ferrari.pro.br Tue Sep 14 18:49:51 2010 From: fabricio at ferrari.pro.br (Fabricio Ferrari) Date: Tue, 14 Sep 2010 19:49:51 -0300 Subject: [AstroPy] Pyfits writeto w/ clobber In-Reply-To: <20100914174704.ACH26323@comet.stsci.edu> References: <20100914174704.ACH26323@comet.stsci.edu> Message-ID: Dear Jim Of course you are right, pyfits 1.3 is very old. But I have ubuntu 10.04 with pyfits from the repository. It should be a newer version, I really don't know what happened. If I do: import pyfits print pyfits.__version__ I got the 1.3 version Does anyone has a similar problem? Thanks Fabricio ..-. ..-. Fabricio Ferrari? ? ?? [www.ferrari.pro.br] Brasil 2010/9/14 : > Fabricio, > > ? ?I don't know about version 1.3 of pyfits which is several years old, but the current version is 2.3.1 and the clobber argument to pyfits.writeto() works correctly. ?You may get the latest version of pyfits from http://www.stsci.edu/resources/software_hardware/pyfits/Download. > > ? ? Jim T. > From superluminique at gmail.com Tue Sep 14 19:09:32 2010 From: superluminique at gmail.com (Rene Breton) Date: Tue, 14 Sep 2010 19:09:32 -0400 Subject: [AstroPy] Pyfits writeto w/ clobber In-Reply-To: References: <20100914174704.ACH26323@comet.stsci.edu> Message-ID: Hi Fabricio, I'm also on Ubuntu 10.04 and the version of pyfits in the repository is indeed very old; v1.3. I would highly recommend that you install pyfits manually from the tarball there: http://www.stsci.edu/resources/software_hardware/pyfits/Download. Perhaps pypi has a pyfits bundle but I haven't checked. Rene On 2010-09-14, at 6:49 PM, Fabricio Ferrari wrote: > Dear Jim > > Of course you are right, pyfits 1.3 is very old. But I have ubuntu > 10.04 with pyfits from the repository. > It should be a newer version, I really don't know what happened. > > If I do: > import pyfits > print pyfits.__version__ > > I got the 1.3 version > > Does anyone has a similar problem? > > Thanks > Fabricio > > ..-. ..-. > Fabricio Ferrari [www.ferrari.pro.br] > Brasil > > > > 2010/9/14 : >> Fabricio, >> >> I don't know about version 1.3 of pyfits which is several years old, but the current version is 2.3.1 and the clobber argument to pyfits.writeto() works correctly. You may get the latest version of pyfits from http://www.stsci.edu/resources/software_hardware/pyfits/Download. >> >> Jim T. >> > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From fabricio at ferrari.pro.br Tue Sep 14 19:19:56 2010 From: fabricio at ferrari.pro.br (Fabricio Ferrari) Date: Tue, 14 Sep 2010 20:19:56 -0300 Subject: [AstroPy] Pyfits writeto w/ clobber In-Reply-To: References: <20100914174704.ACH26323@comet.stsci.edu> Message-ID: Yes, I'll certainly install from the repository. but now I began to doubt other 'taken for granted' repository packages as well. Thank you very much., cheers F ..-. ..-. Fabricio Ferrari? ? ?? [www.ferrari.pro.br] Brasil 2010/9/14 Rene Breton : > Hi Fabricio, > > I'm also on Ubuntu 10.04 and the version of pyfits in the repository is indeed very old; v1.3. I would highly recommend that you install pyfits manually from the tarball there: http://www.stsci.edu/resources/software_hardware/pyfits/Download. Perhaps pypi has a pyfits bundle but I haven't checked. > > Rene From william.t.bridgman at nasa.gov Wed Sep 15 08:52:45 2010 From: william.t.bridgman at nasa.gov (Bridgman, William T.) Date: Wed, 15 Sep 2010 08:52:45 -0400 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: <20100914172958.ACH26053@comet.stsci.edu> References: <20100914172958.ACH26053@comet.stsci.edu> Message-ID: <1FFF58F0-41DB-4C4A-8640-FD051185499D@nasa.gov> Jim, That's what I suspect, I just want to produce a full list of them. Now it appears that if I raise the warning to an exception, it skips the header load which causes my file summary section (which parses the file header) to fail. I seem to be faced with the choice of 1) recording the warning, and not getting info on data that is otherwise at least partially readable, or 2) not capturing the warning and getting a file summary. I have a couple of ideas for getting around this issue, but none of them are very clean. Now I can fall completely into the camp that this type of warning should *not* be treated as an error. Right now, the files indicating problems are not the ones I need for my current project so I will have to shelve this problem for now. Thanks for your assistance, Tom On Sep 14, 2010, at 5:29 PM, jtaylor2 at stsci.edu wrote: > Tom, > > Based on the warning message you are getting, your file is indeed > corrupt. The file size 2102784 is not a multiple of 2880 so their > must be a problem with the file. Your problem may be the same as > Anne has indicated or it may not. At any rate, the file you have is > not fits complient. Although PyFITS may be able to handle the > extensions in the file that are. > > 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/ From sienkiew at stsci.edu Wed Sep 15 09:44:54 2010 From: sienkiew at stsci.edu (Mark Sienkiewicz) Date: Wed, 15 Sep 2010 09:44:54 -0400 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: <1FFF58F0-41DB-4C4A-8640-FD051185499D@nasa.gov> References: <20100914172958.ACH26053@comet.stsci.edu> <1FFF58F0-41DB-4C4A-8640-FD051185499D@nasa.gov> Message-ID: <4C90CDD6.9000602@stsci.edu> On 9/15/10 8:52 AM, Bridgman, William T. wrote: > Now it appears that if I raise the warning to an exception, it skips > the header load which causes my file summary section (which parses the > file header) to fail. > > I seem to be faced with the choice of > > 1) recording the warning, and not getting info on data that is > otherwise at least partially readable, or > 2) not capturing the warning and getting a file summary. The third option is to replace the function that displays the warnings, so that you can collect the warnings and examine them after the function call returns. Try something like this: # import pyfits first - it messes with warnings too, and we # want our changes to happen later import pyfits # a list where all the warnings will be collected wlist = [ ] # a function that collects warnings into the list, instead of # printing them def my_showwarning(message, category, filename, lineno, file=None): wlist.append( (message, category, filename, lineno ) ) # monkey patch the warnings package to use our function import warnings warnings.showwarning = my_showwarning # do something that causes a warning warnings.warn('Test warning') hdulist = pyfits.open( ... ) # see if any warnings were in the list if len(wlist) > 0 : print "warnings happened:", wlist # detect if anybody else changed showwarning - if they did, # we might not have collected all the warnings in wlist. if warnings.showwarning != my_showwarning : print "somebody changed showwarning when I wasn't looking!" # now examine the file with pyfits ... whatever you originally planned to do ... The documentation for the warnings module ( http://docs.python.org/library/warnings.html#warning-filter ) alludes to doing something like this ("user-settable hook"), but it doesn't explicitly say that this is how to do it. If you look at lib/python2.5/warnings.py, it is pretty clear that this how it is supposed to work. You could, of course, run in to conflicts with other packages that try to do the same thing. This include pyfits (!), but if you import it _before_ you monkey patch the warnings module, your changes will supersede the changes that pyfits made. It's ok. I looked at pyfits and tried this sample code on a fits file that was a few bytes short, and it worked as expected. It looks a little kludgey, but that is how the warnings module is intended to work. Regards, Mark S From jtaylor2 at stsci.edu Wed Sep 15 10:06:21 2010 From: jtaylor2 at stsci.edu (jtaylor2 at stsci.edu) Date: Wed, 15 Sep 2010 10:06:21 -0400 (EDT) Subject: [AstroPy] Capturing pyfits warnings Message-ID: <20100915100621.ACH36953@comet.stsci.edu> 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. From william.t.bridgman at nasa.gov Wed Sep 15 10:26:10 2010 From: william.t.bridgman at nasa.gov (Bridgman, William T.) Date: Wed, 15 Sep 2010 10:26:10 -0400 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: <20100915100621.ACH36953@comet.stsci.edu> References: <20100915100621.ACH36953@comet.stsci.edu> Message-ID: 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. 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/ From Jim.Vickroy at noaa.gov Wed Sep 15 11:09:01 2010 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed, 15 Sep 2010 09:09:01 -0600 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: References: <20100915100621.ACH36953@comet.stsci.edu> Message-ID: <4C90E18D.7080801@noaa.gov> Please excuse this non-Python proposal, but would it be worth considering FTOOLS (in particular fverify ) to accomplish this task? -- jv Bridgman, William T. 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. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aarchiba at physics.mcgill.ca Wed Sep 15 11:17:32 2010 From: aarchiba at physics.mcgill.ca (Anne Archibald) Date: Wed, 15 Sep 2010 11:17:32 -0400 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: References: <20100915100621.ACH36953@comet.stsci.edu> Message-ID: On 15 September 2010 10:26, Bridgman, William T. 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 > From laidler at stsci.edu Wed Sep 15 11:58:07 2010 From: laidler at stsci.edu (Victoria G. Laidler) Date: Wed, 15 Sep 2010 11:58:07 -0400 (EDT) Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: References: <20100915100621.ACH36953@comet.stsci.edu> Message-ID: <20100915115807.ACH40847@comet.stsci.edu> 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 ) >Subject: Re: [AstroPy] Capturing pyfits warnings >To: "Bridgman, William T." >Cc: AstroPy > >On 15 September 2010 10:26, Bridgman, William T. > 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 From william.t.bridgman at nasa.gov Wed Sep 15 12:28:45 2010 From: william.t.bridgman at nasa.gov (Bridgman, William T.) Date: Wed, 15 Sep 2010 12:28:45 -0400 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: <4C90E18D.7080801@noaa.gov> References: <20100915100621.ACH36953@comet.stsci.edu> <4C90E18D.7080801@noaa.gov> Message-ID: <8B0FFD25-48F1-4C0D-8D76-85B1A232996A@nasa.gov> Jim, Beyond another package with a learning curve of limited use in our environment, probably not. I occasionally use FV, but that is pretty stand-alone. Because we work with so many datasets from a wide variety of missions (Earth/geospace/solar) and often *combine* them to tell stories, we have lots of packages installed - enough that we've had significant name collisions and path problems between them. Tom On Sep 15, 2010, at 11:09 AM, Jim Vickroy wrote: > Please excuse this non-Python proposal, but would it be worth > considering FTOOLS (in particular fverify) to accomplish this task? > -- jv > > Bridgman, William T. 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. >> >> 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 >> > -- 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/ From william.t.bridgman at nasa.gov Wed Sep 15 12:39:39 2010 From: william.t.bridgman at nasa.gov (Bridgman, William T.) Date: Wed, 15 Sep 2010 12:39:39 -0400 Subject: [AstroPy] Capturing pyfits warnings In-Reply-To: <20100915115807.ACH40847@comet.stsci.edu> References: <20100915100621.ACH36953@comet.stsci.edu> <20100915115807.ACH40847@comet.stsci.edu> Message-ID: <3EB83DB5-9376-4DAF-B011-9E6059A62F4E@nasa.gov> 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 at scipy.org (on behalf of Anne Archibald > >) >> Subject: Re: [AstroPy] Capturing pyfits warnings >> To: "Bridgman, William T." >> Cc: AstroPy >> >> On 15 September 2010 10:26, Bridgman, William T. >> 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 > _______________________________________________ > AstroPy mailing list > AstroPy at 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 at nasa.gov Code 610.3 Phone: 301-286-1346 Greenbelt, MD 20771 FAX: 301-286-1634 http://svs.gsfc.nasa.gov/ From sergiopr at fis.ucm.es Thu Sep 16 06:04:00 2010 From: sergiopr at fis.ucm.es (Sergio Pascual) Date: Thu, 16 Sep 2010 12:04:00 +0200 Subject: [AstroPy] Pyfits writeto w/ clobber In-Reply-To: References: <20100914174704.ACH26323@comet.stsci.edu> Message-ID: You may consider opening a bug request here https://launchpad.net/ubuntu/+bugs to update pyfits to newer version. This will help other ubuntu users. 2010/9/15 Fabricio Ferrari : > Yes, I'll certainly install from the repository. > > but now I began to doubt other 'taken for granted' repository packages as well. > > Thank you very much., > > cheers > > F > ..-. ..-. > Fabricio Ferrari? ? ?? [www.ferrari.pro.br] > Brasil > > > 2010/9/14 Rene Breton : >> Hi Fabricio, >> >> I'm also on Ubuntu 10.04 and the version of pyfits in the repository is indeed very old; v1.3. I would highly recommend that you install pyfits manually from the tarball there: http://www.stsci.edu/resources/software_hardware/pyfits/Download. Perhaps pypi has a pyfits bundle but I haven't checked. >> >> Rene > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- Sergio Pascual ? ? ? ? ? ? ? ? ? ? ? ?http://guaix.fis.ucm.es/~spr gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain) From J.P.Terlouw at astro.rug.nl Thu Sep 16 07:10:50 2010 From: J.P.Terlouw at astro.rug.nl (Hans Terlouw) Date: Thu, 16 Sep 2010 13:10:50 +0200 Subject: [AstroPy] ANN: Kapteyn Package 2.0.2 released Message-ID: <4C91FB3A.9080009@astro.rug.nl> We are pleased to announce the release of version 2.0.2 of the Kapteyn Package. The Kapteyn Package is a collection of Python modules developed by the computer group of the Kapteyn Astronomical Institute, University of Groningen, The Netherlands. Some of the package's features: - The handling of spatial and spectral coordinates, WCS projections and transformations between different sky systems. Spectral translations (e.g. between frequencies and velocities) are supported as well as mixed coordinates. For WCS, Dr. Mark Calabretta's WCSLIB is used. - Versatile tools for writing small and dedicated applications for the inspection of FITS headers, the extraction, display and interactive inspection of (FITS) data and for the creation of plots with world coordinate information, including all-sky plots. A unique feature is the possibility to make plots with mixed coordinates, e.g. where one axis is spatial and the other one is spectral. Matplotlib and PyFITS are used. - Tools for parsing and interpreting coordinate information entered by the user. - Utilities for use with Matplotlib such as obtaining coordinate information from plots, interactively modifiable colormaps and timer events (to facilitate movie loops). - A class for the efficient reading, writing and manipulating of simple table-like structures in text files. Currently supported architectures are Linux, Apple Mac OS X and Microsoft Windows. Extensive documentation, including tutorial and background information, as well as download and installation instructions can be found at http://www.astro.rug.nl/software/kapteyn/ We look forward to your feedback. Hans Terlouw and Martin Vogelaar -- J. P. Terlouw Kapteyn Astronomical Institute University of Groningen Postbus 800 NL-9700 AV Groningen The Netherlands Phone: +31-(0)50-3634068/73 Fax: +31-(0)50-3636100 From ralf.kotulla at gmail.com Wed Sep 22 22:12:45 2010 From: ralf.kotulla at gmail.com (Ralf Kotulla) Date: Wed, 22 Sep 2010 21:12:45 -0500 Subject: [AstroPy] wregister won't work under python/pyraf Message-ID: <4C9AB79D.9080208@gmail.com> Dear all, I'm currently trying to finish a small near-infrared data reduction pipeline in python/pyraf. As part of the alignment process I was planning to use wregister as a rough alignment and then refine the solution using xregister. However, while this procedure works perfectly fine in "traditional" IRAF, I can't get it to work in pyraf. The code-snippet causing the problem is the following: iraf.images.immatch.wregister( \ input=inputfile, \ reference=referencefile, \ output=tmp_wregister) where all inputfile, referencefile and tmp_wregister are fits-files. As mentioned above, running wregister on exactly the same files with identical parameters in ecl works fine, but in python it brings up this: Traceback (most recent call last): File "./reduce.py", line 541, in align(filenames) File "./reduce.py", line 441, in align gcommand="q.txt") File "/usr/local/lib/python2.6/site-packages/pyraf/iraftask.py", line 699, in __call__ return apply(self.run,args,kw) File "/usr/local/lib/python2.6/site-packages/pyraf/iraftask.py", line 302, in run self._run(redirKW, specialKW) File "/usr/local/lib/python2.6/site-packages/pyraf/iraftask.py", line 1371, in _run self._runCode() File "/usr/local/lib/python2.6/site-packages/pyraf/iraftask.py", line 1386, in _runCode apply(self._clFunction, parList, kw) File "", line 129, in wregister File "/usr/local/lib/python2.6/site-packages/pyraf/iraftask.py", line 699, in __call__ return apply(self.run,args,kw) File "/usr/local/lib/python2.6/site-packages/pyraf/iraftask.py", line 303, in run self._updateParList(save) File "/usr/local/lib/python2.6/site-packages/pyraf/iraftask.py", line 780, in _updateParList rv = self.saveParList() File "/usr/local/lib/python2.6/site-packages/pyraf/iraftask.py", line 627, in saveParList rv = self._currentParList.saveParList(filename, comment) File "/usr/local/lib/python2.6/site-packages/pyraf/irafpar.py", line 842, in saveParList absFileName = iraf.Expand(filename) File "/usr/local/lib/python2.6/site-packages/pyraf/iraffunctions.py", line 3018, in Expand outlist.append(_os.path.expanduser(_expand1(word, noerror=noerror))) File "/usr/local/lib/python2.6/site-packages/pyraf/iraffunctions.py", line 3051, in _expand1 (varname, instring)) pytools.irafglobals.IrafError: Undefined variable `uparm' in string `uparm$imlsectis.par' I also tried to unlearn wregister just in case some queer parameter was causing this, but no change... Any idea what might be causing this or how to fix / work around this? Best wishes and thanks a lot in advance Ralf p.s. Just for the record, I'm using - python 2.6 (r26:66714, Mar 30 2010, 00:30:21) , - PyRAF 1.9 (May 2010) Copyright (c) 2002 AURA - openSuSE 11.1, kernel 2.6.27.48-0.2-pae #1 SMP 2010-07-29 20:06:52 +0200 i686 i686 i386 GNU/Linux -- ======================================================= Ralf Kotulla kotulla at uwm.edu - Center for Gravitation and Cosmology, Dept. of Physics University of Wisconsin - Milwaukee 1900 E Kenwood Blvd, Milwaukee, WI 53211, USA Tel: +1 (414) 229-5268 / Fax: +1 (414) 229-5589 - Professional webpage: http://www.galev.org Personal webpage: http://members.galev.org/rkotulla -------------- next part -------------- An HTML attachment was scrubbed... URL: From luigi at lambrate.inaf.it Thu Sep 23 08:00:19 2010 From: luigi at lambrate.inaf.it (Luigi Paioro) Date: Thu, 23 Sep 2010 14:00:19 +0200 Subject: [AstroPy] SAMPy release 1.2.0 Message-ID: <4C9B4153.9030305@lambrate.inaf.it> Dear All, we are pleased to announce the new SAMPy release 1.2.0, available at PANDORA group site: http://cosmos.iasf-milano.inaf.it/pandora/ This is the ChangeLog: - Fully support to SAMP_HUB environment variable as specified in SAMP 1.2 protocol. - Added the possibility of specify a custom lockfile explicitly when a new hub instance is created (-f or --lockfile from command line, lockfile parameter of SAMPHubServer class). - SAMPClient and SAMPIntegratedClient updated adding a generic bindReceiveMessage method, which allows to bind a single function to calls and notifications. - Added SAMPMsgReplierWrapper decorator class/function, useful to wrap bound functions that might return a response (calls or generic functions passed to bindReceiveMessage). This decorator accepts a client instance as argument and allows to return response parameters as a simple map (without the need of explicitly call the reply operation). - eclient.py example script added showing the decorators use. - http_file_server.py utility script added. It is able to serve a lockfile (or any other file) through an HTTP address. ********* IMPORTANT NOTE ********* We wish to draw your attention on the following message, also posted on the PANDORA home page: After more than five years, due to lack of manpower and funds, we cannot support the Pandora programs and help-desk any more. As from October first 2010, the help-desk will be unavailable, and programs will not be updated any more, not even for bug fixing. The current version of SAMPy and all our programs will remain available for download for a few months, without any support or guarantee for installation and usage. If during these five years you have appreciated our work, and wish to support us for a last attempt to raise funds, you may go to this link and subscribe our petition. http://cosmos.iasf-milano.inaf.it/pandora/petition.html Sorry if you have received multiple copies of this e-mail. The PANDORA group From sontag at stsci.edu Thu Sep 23 09:42:12 2010 From: sontag at stsci.edu (Chris Sontag) Date: Thu, 23 Sep 2010 09:42:12 -0400 Subject: [AstroPy] wregister won't work under python/pyraf In-Reply-To: <4C9AB79D.9080208@gmail.com> References: <4C9AB79D.9080208@gmail.com> Message-ID: <4C9B5934.8070901@stsci.edu> Hi Ralf, This looks a lot like you are running PyRAF without a login.cl being invoked (where the uparm variable is normally defined) - could this be the case? Hope this helps, Chris On 9/22/10 10:12 PM, Ralf Kotulla wrote: > pytools.irafglobals.IrafError: Undefined variable `uparm' in string `uparm$imlsectis.par' > > I also tried to unlearn wregister just in case some queer parameter was causing this, but no change... > > Any idea what might be causing this or how to fix / work around this? > > Best wishes and thanks a lot in advance > Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldcroft at head.cfa.harvard.edu Thu Sep 23 22:13:33 2010 From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft) Date: Thu, 23 Sep 2010 22:13:33 -0400 Subject: [AstroPy] asciitable 0.3.1 Message-ID: I'd like to announce the release of version 0.3.1 of asciitable, an extensible module for reading and writing ASCII tables. This release features the new capability to write ASCII tables using the same basic infrastructure and API as for reading. http://cxc.harvard.edu/contrib/asciitable/ Other updates include: - Python 3 compatibility - Significant documentation updates - Improved test coverage - New Reader class to read in-memory tables Regards, Tom Aldcroft