[AstroPy] Draft specification for PyFITS functional interface

W.T. Bridgman William.T.Bridgman.1 at gsfc.nasa.gov
Thu Mar 31 08:02:06 CST 2005

Or, to put it more succinctly:

"If I wanted to do procedural programming, I'd stick with IDL."  :^)

I vote for separate modules.  Don't load down the OO module with 
functional wrappers.

On Mar 30, 2005, at 5:36 PM, Tom Loredo wrote:

> Hi folks-
>> one
>> of the things that makes Python so useful is its flexibility and 
>> *lack*
>> of forced adherence to a particular programming style.  Complaints
>> that it would be "polluting" the pyfits interface make no sense to me
> I can't speak for the authors, so perhaps they'll speak for themselves
> on this.
> That said... if the split is made, are you really going to complain
> about having to type:
>   import qpyfits, pyfits
> versus:
>   import pyfits
> (or the two "*" imports) on the occassions when you want both 
> interfaces?
> As a developer, I think the package idea makes sense, (1) to help
> "compartmentalize" development (in that it reflects a logical division
> between the OO stuff that does the work, and the functional stuff that
> is only an interface to the OO stuff), and (2) to prevent *namespace*
> pollution.  Especially interactively, I can be lazy:
>   from pyfits import *
> If I only use the OO stuff, why should I fill my namespace (esp. in a
> module that might itself get imported elsewhere) with all the other
> stuff?  If you believe that users who use the functional interface will
> often want the OO stuff, we can simply arrange that the qpyfits (or
> whatever) module import the OO stuff into its namespace, so if you do:
>   from qpyfits import *
> you have everything (I'm not advocating this necessarily, but
> it could be a way to have and eat the cake).  Or we can define
> pyfits this way, but have under it a separate oofits module that
> we could import by itself (pyfits.oofits?) when we write a module
> or script that just uses the OO stuff.  pyfits.py would just
> "suck" the oofits stuff into its namespace (perhaps by judicious
> use of __all__ within the various modules).
> I don't know what the big deal is regarding this.  Any of the
> possible choices will be easy to live with.  FITS stuff is
> such a pain (perhaps not incredibly difficult, but definitely
> no fun!) that I'm just grateful the PyFITS team is doing
> *anything* that takes that load off my back!  Yea team!
> Cheers,
> Tom
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.net
> http://www.scipy.net/mailman/listinfo/astropy
Dr. William T."Tom" Bridgman               Scientific Visualization 
Global Science & Technology, Inc.          NASA/Goddard Space Flight 
Email: William.T.Bridgman.1 at gsfc.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