[AstroPy] PyFITS beta testing
Mon Nov 28 09:34:28 CST 2011
Thanks for pointing that out Philip. Bringing this back to the list if
you don't mind.
PyFITS doesn't normally include documentation for building the docs
since normally users don't have to. But I should add some anyways.
Building the PyFITS docs requires the stsci.sphinxext package, which can
be downloaded from PyPI (http://pypi.python.org/pypi/stsci.sphinxext)
and installed with easy_install, pip, etc.
However, I went up and put a version of the docs from the header branch
http://stsdas.stsci.edu/download/docs/pyfits/header-refactoring/ so you
shouldn't have to bother.
The main differences are in all the header-specific docs:
These docs now explain the new way of working with Headers (which isn't
much different for the most part). The old ways should work too. I'm
interested both in feedback on the new API and whether or not it makes
sense, as well as on how well backwards compatibility has been
maintained with your old code.
On 11/25/2011 09:10 PM, Philip Tait wrote:
> Hi Erik,
> I thought I would give this a try. The PyFITS module built OK, but I
> seem to be missing a module needed to build the docs:
>> make html
> sphinx-build -b html -d build/doctrees source build/html
> Making output directory...
> Running Sphinx v1.0.7
> Exception occurred:
> File "/home/pjt/pyfits/header-refactoring/docs/source/conf.py", line
> 17, in<module>
> from stsci.sphinxext.conf import *
> ImportError: No module named stsci.sphinxext.conf
> Clues welcome.
> On Wed, Nov 16, 2011 at 11:59, Erik Bray<firstname.lastname@example.org> wrote:
>> Hi all,
>> I've been working off and on for a few months on a big changeset to
>> PyFITS which changes some details about how Headers are worked with.
>> The biggest overall change to be aware of is that the CardList class is
>> completely deprecated. Headers are worked with entirely through Header
>> objects, which have assumed much of the former responsibility of CardLists.
>> Header objects themselves work mostly the same way as before, but they
>> are now more powerful objects that combine a mostly transparent
>> interface to header as an ordered dict-like object with a list-like
>> interface that allows manipulating a Header on the level of individual
>> The pyfits.Card class is still in use, but there are not many reasons to
>> use it directly. All methods that accept a Card object will also accept
>> a simple (keyword, value, comment) tuple in its place, or even (keyword,
>> value) tuples.
>> I've also worked hard to maintain backwards compatibility for now with
>> the old API. There is still a class called CardList, for example, and
>> it works similarly to the old class. There's no reason to use it,
>> however, except to support older code. I've tested the backwards
>> compatibility pretty extensively through the stsci_python regtests. So
>> far I've only found one (rare) use case that is not backwards
>> compatible, but that is a one line fix (it has to do with iteration over
>> slices of Headers--I'll give more details if anyone asks).
>> So I'm sending out a call to get a couple of people to try out the new
>> interface and see how it works for them. I'm interested in both
>> backwards compatibility with old code, and in opinions on the new API.
>> Nothing here is set in stone, so as much feedback as I can get would be
>> greatly appreciated.
>> The new code can be found at:
>> The branch is kept up to date with pyfits's trunk, so if you already do
>> any development off of that the only major changes should be to headers.
>> AstroPy mailing list
More information about the AstroPy