From dfnsonfsduifb at gmx.de  Wed Jun  3 09:25:57 2009
From: dfnsonfsduifb at gmx.de (Johannes Bauer)
Date: Wed, 03 Jun 2009 15:25:57 +0200
Subject: [AstroPy] PyFITS warning not supplying "line" argument
Message-ID: <4A2679E5.70805@gmx.de>

Hello group,

after updating my system to Ubuntu Jaunty, my code now throws an
exception of which the source I believe resides within pyfits. The code
the exception is throw is however in gtk code:

pb = gtk.gdk.Pixbuf(gtk.gdk.COLORSPACE_RGB, False, 8, width, height)
pb_pixels = pb.get_pixels_array()

and the result in the application:

./guiclient.py:294: DeprecationWarning: functions overriding
warnings.showwarning() must support the 'line' argument
  pb_pixels = pb.get_pixels_array()
Traceback (most recent call last):
  File "./guiclient.py", line 359, in on_Result
    self.__updateimage()
  File "./guiclient.py", line 294, in __updateimage
    pb_pixels = pb.get_pixels_array()
  File "/var/lib/python-support/python2.6/pyfits/NP_pyfits.py", line 76,
in showwarning
    _showwarning(message, category, filename, lineno, file)
  File "/usr/lib/python2.6/warnings.py", line 30, in _show_warning
    file.write(formatwarning(message, category, filename, lineno, line))
TypeError: formatwarning() takes exactly 4 arguments (5 given)

Now when I insert into "/usr/lib/python2.6/warnings.py" at line 29

print(message, category, filename, lineno, line)

I get:

(DeprecationWarning('PyArray_FromDimsAndDataAndDescr: use
PyArray_NewFromDescr.',), <type 'exceptions.DeprecationWarning'>,
'./guiclient.py', 294, None)

Now why I think that it's pyfits has the following reason: Consider this
code:

#!/usr/bin/python
import gtk
gtk.gdk.Pixbuf(gtk.gdk.COLORSPACE_RGB, False, 8, 123,
123).get_pixels_array()

when executed, it says:

./x:3: DeprecationWarning: PyArray_FromDimsAndDataAndDescr: use
PyArray_NewFromDescr.
  gtk.gdk.Pixbuf(gtk.gdk.COLORSPACE_RGB, False, 8, 123,
123).get_pixels_array()

Now consider this changed piece of code

./x:4: DeprecationWarning: functions overriding warnings.showwarning()
must support the 'line' argument
  gtk.gdk.Pixbuf(gtk.gdk.COLORSPACE_RGB, False, 8, 123,
123).get_pixels_array()
Traceback (most recent call last):
  File "./x", line 4, in <module>
    gtk.gdk.Pixbuf(gtk.gdk.COLORSPACE_RGB, False, 8, 123,
123).get_pixels_array()
  File "/var/lib/python-support/python2.6/pyfits/NP_pyfits.py", line 76,
in showwarning
    _showwarning(message, category, filename, lineno, file)
  File "/usr/lib/python2.6/warnings.py", line 29, in _show_warning
    file.write(formatwarning(message, category, filename, lineno, line))
TypeError: formatwarning() takes exactly 4 arguments (5 given)

Is there anything I can do about the exception being thrown? Does it
really originate from pyfits or is it from pygtk?

Kind regards,
Johannes


From jtaylor2 at stsci.edu  Wed Jun  3 10:22:44 2009
From: jtaylor2 at stsci.edu (jtaylor2 at stsci.edu)
Date: Wed,  3 Jun 2009 10:22:44 -0400 (EDT)
Subject: [AstroPy] PyFITS warning not supplying "line" argument
Message-ID: <20090603102244.ABC52112@comet.stsci.edu>

Johannes,

    This exception is raised due to a change in the warnings module made in python 2.6.  The current version of pyfits (version 2.1.1) contains a fix for this problem.  You may download the latest version at our download website http://www.stsci.edu/resources/software_hardware/pyfits/Download.


    Jim T.



From jh at physics.ucf.edu  Mon Jun  8 16:02:36 2009
From: jh at physics.ucf.edu (Joe Harrington)
Date: Mon, 08 Jun 2009 16:02:36 -0400
Subject: [AstroPy] The SciPy Doc Marathon continues
Message-ID: <wl8vdn64hpf.fsf@glup.physics.ucf.edu>

		   Let's Finish Documenting SciPy!

Last year, we began the SciPy Documentation Marathon to write
reference pages ("docstrings") for NumPy and SciPy.  It was a huge
job, bigger than we first imagined, with NumPy alone having over 2,000
functions.

We created the doc wiki (now at docs.scipy.org), where you write,
review, and proofread docs that then get integrated into the source
code.  In September, we had over 55% of NumPy in the "first draft"
stage, and about 25% to the "needs review" stage.  The PDF NumPy
Reference Guide was over 300 pages, nicely formatted by ReST, which
makes an HTML version as well.  The PDF document now has over 500
pages, with the addition of sections from Travis Oliphant's book Guide
to NumPy.

That's an amazing amount of work, possible through the contributions
of over 30 volunteers.  It came back to us as the vastly-expanded help
pages in NumPy 1.2, released last September.

With your help, WE CAN FINISH!  This summer we can:

- Write all the "important" NumPy pages to the "Needs Review" stage
- Start documenting the SciPy package
- Get the SciPy User Manual started
- Implement dual review - technical and presentation - on the doc wiki
- Get NumPy docs and packaging on a sound financial footing

We'll start with the first two.  UCF has hired David Goldsmith to lead
this summer's doc effort.  David will write a lot of docs himself, but
more importantly, he will organize our efforts toward completing doc
milestones.  There will be rewards, T-shirts, and likely other fun
stuff for those who contribute the most.  David will start the ball
rolling shortly.

This is a big vision, and it will require YOUR help to make it happen!

The main need now is for people to work on the reference pages.
Here's how:

1. Go to http://docs.scipy.org/NumPy
2. Read the intro and doc standards, and some docstrings on the wiki
3. Make an account
4. Ask the scipy-dev at scipy.org email list for editor access
5. EDIT!

All doc discussions (except announcements like this one) should happen
on the scipy-dev at scipy.org email list.  You can browse the archives
and sign up for the list at http://scipy.org/Mailing_Lists .  That's
where we will announce sprints on topic areas and so on.

We'll also meet online every week, Wednesdays at 4:30pm US Eastern Time,
on Skype.  David will give the details.

Welcome back to the Marathon!

--jh--
Prof. Joseph Harrington
Planetary Sciences Group
Department of Physics
MAP 414
4000 Central Florida Blvd.
University of Central Florida
Orlando, FL 32816-2385
jh at physics.ucf.edu
planets.ucf.edu



From d_l_goldsmith at yahoo.com  Mon Jun  8 18:10:43 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Mon, 8 Jun 2009 15:10:43 -0700 (PDT)
Subject: [AstroPy] Summer NumPy Doc Marathon (Reply-to: scipy-dev@scipy.org)
Message-ID: <621234.10773.qm@web52111.mail.re2.yahoo.com>


Dear SciPy Community Members:

     Hi!  My name is David Goldsmith.  I've been hired for the summer by Joe Harrington to further progress on NumPy documentation and ultimately, pending funding, SciPy documentation.  Joe and I are reviving last summer?s enthusiasm in the community for this mission and enlisting as many of you as possible in the effort.  On that note, please peruse the NumPy Doc Wiki (http://docs.scipy.org/numpy/Front Page/) and, in particular, the master list of functions/objects (?items?) needing work
(http://docs.scipy.org/numpy/Milestones/).  Our goal is to have every item to the ready-for-first-review stage (or better) by August 18 (i.e., the start of SciPyCon09).  To accomplish this, we're forming teams to attack each doc category on the Milestones page.

     From the Milestones page:

"To speed things up, get more uniformity in the docs, and add a social element, we're attacking these categories as teams. A team lead takes responsibility for getting a category to "Needs review" within one month [we expect that some categories will require less time ? please furnish your most ?optimistically realistic? deadline when ?claiming? a category], but no later than 18 August 2009. As leader, you commit to working with anyone who signs up in your category, and vice versa. The scipy-dev mailing list is a great place to recruit helpers.

"Major doc contributors will be listed in NumPy's contributors file, THANKS.txt. Anyone writing more than 1000 words will get a T-shirt (while supplies last, etc.). Teams that reach their goals in time will get special mention in THANKS.txt.

"Of course, you don't have to join a team. If you'd like to work on your own, please choose docstrings from an unclaimed category, and put your name after docstrings you are editing in the list below. If someone later claims that category, please coordinate with them or finish up your current docstrings and move to another category."

     Please note that, to edit anything on the Wiki (including the doc itself), you?ll need ?edit rights? ? how you get these is Item 5 under ?Before you start? on the ?Front Page,? but for your convenience, I?ll quote that here:

"Register a username on [docs.scipy.org]. Send an e-mail with your username to the scipy-dev mailing list (requires subscribing to the mailing list first, [which can be done at
http://mail.scipy.org/mailman/listinfo/scipy-dev]), so that we can give you edit rights. If you are not subscribed to the mailing-list, you can also send an email to gael dot varoquaux at normalesup dot org, but this will take longer [and you?ll want to subscribe to scipy-dev anyway, because that?s the place to post questions and comments about this whole doc development project]."

     Also, I?ll be holding a weekly Skype (www.skype.com) telecon ? Wednesdays at 4:30pm US Eastern Daylight Time - to review progress and discuss any roadblocks we may have encountered (or anticipate encountering).  If you?d like to participate and haven?t already downloaded and installed Skype and registered a Skype ID, you should do those things; then, you'll be able to join in simply by "Skyping" me (Skype ID: d.l.goldsmith) and I'll add you to the call.

     So, thanks for your time reading this, and please make time this summer to help us meet (or beat) the goal.

Sincerely,

David Goldsmith, Technical Editor
Olympia, WA



      


From d_l_goldsmith at yahoo.com  Tue Jun  9 02:11:59 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Mon, 8 Jun 2009 23:11:59 -0700 (PDT)
Subject: [AstroPy] More on Summer NumPy Doc Marathon
Message-ID: <901731.25166.qm@web52108.mail.re2.yahoo.com>


Hi again, folks.  I have a special request.  Part of the vision for my job is that I'll focus my writing efforts on the docs no one else is gung-ho to work on.  So, even if you're not quite ready to commit, if you're leaning toward volunteering to be a team lead for one (or more) categories, please let me know which one(s) (off list, if you prefer) so I can get an initial idea of what the "leftovers" are going to be.  Thanks!

DG


      


From d_l_goldsmith at yahoo.com  Tue Jun  9 12:31:25 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 9 Jun 2009 09:31:25 -0700 (PDT)
Subject: [AstroPy] [SciPy-dev] More on Summer NumPy Doc Marathon
Message-ID: <667868.5819.qm@web52110.mail.re2.yahoo.com>


Thanks, Stefan.  The lists you suggest already exist (more or less, depending on the "thing," i.e., list of categories, completely, prioritized list of individual items, sort of, at least w/in the categories) on the Milestones page (that's essentially what the Milestones page is) and the list of individual items is far too long to duplicate here, but for everyone's convenience I'll provide the list of categories (at least those for which the goal has not been, or is not close to being, met, which is most of them):

Data type investigation
Fourier transforms
Linear algebra
Error handling
Financial functions
Functional operations
Help routines
Indexing
Input/Output
Logic, comparisons etc.
Polynomials
Random number generation
Other random operations
Boolean set operations
Searching
Sorting
Statistics
Comparison
Window functions
Sums, interpolation, gradients, etc
Arithmetic + basic functions I
Arithmetic + basic functions II
Arithmetic + basic functions III
Masked arrays
Masked arrays, II
Masked arrays, III
Masked arrays, IV
Operations on masks
Even more MA functions I
Even more MA functions II
Numpy internals
C-types
Other math
The matrix library
Numarray compatibility
Numeric compatibility
Other array subclasses
Matrix subclass
Ndarray
Ndarray, II
Dtypes
Ufunc
Scalar base class
Scalar types

Comments:

0) The number of individual items in each of these categories varies from one to a few dozen or so

1) Omitted are a few "meta-categories," e.g., "Routines," "Basic Objects," etc.

2) IMO, there are still too many of these (at least too many to not be intimidating in the manner Stefan has implied); I had it in mind to try to create an intermediate level of organization, i.e., "meso-categories," but I couldn't really justify it on grounds other than there are simply still too many categories to be unintimidating, so I was advised against usage of time in that endeavor.  However, if there's an outpouring of support for me doing that, it would fall on sympathetic ears.

As far as prioritizing individual items, my opinion is that team leads should do that (or not, as they deem appropriate) - I wouldn't presume to know enough to do that in most cases.  However, if people want to furnish me with suggested prioritizations, I'd be happy to be the one to edit the Wiki to reflect these.

DG

--- On Tue, 6/9/09, St?fan van der Walt <stefan at sun.ac.za> wrote:

> From: St?fan van der Walt <stefan at sun.ac.za>
> Subject: Re: [SciPy-dev] More on Summer NumPy Doc Marathon
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Date: Tuesday, June 9, 2009, 1:34 AM
> Hi David
> 
> 2009/6/9 David Goldsmith <d_l_goldsmith at yahoo.com>:
> >
> > Hi again, folks. ?I have a special request. ?Part of
> the vision for my job is that I'll focus my writing efforts
> on the docs no one else is gung-ho to work on. ?So, even if
> you're not quite ready to commit, if you're leaning toward
> volunteering to be a team lead for one (or more) categories,
> please let me know which one(s) (off list, if you prefer) so
> I can get an initial idea of what the "leftovers" are going
> to be. ?Thanks!
> 
> That's a pretty wide question.? Maybe you could post a
> list of
> categories and ask who would be willing to mentor and write
> on each?
> For the writing, we could decide on a prioritised list of
> functions,
> publish that list and then document those entries one by
> one (i.e.
> make the tasks small enough so that people don't run away
> screaming).
> 
> Cheers
> St?fan
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From d_l_goldsmith at yahoo.com  Tue Jun  9 13:31:47 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 9 Jun 2009 10:31:47 -0700 (PDT)
Subject: [AstroPy] [SciPy-dev] More on Summer NumPy Doc Marathon
Message-ID: <570350.72787.qm@web52101.mail.re2.yahoo.com>


Thanks, Bruce.

--- On Tue, 6/9/09, Bruce Southey <bsouthey at gmail.com> wrote:

> Hi,
> Great.
> Can you provide the actual colors at the start for :
> ? ? * Edit white, light gray, or yellow
> ? ? * Don't edit dark gray
> While not color-blind, not all browsers render the same
> colors on all 
> operating systems etc.
> What are you using for light gray or is that meant to be
> blue. If it is 
> 'blue' then what does it mean?
> It appears to be the same color used on the Front Page to
> say 'Proofed'.

Yes, by all means, I agree 100% (I'm having the same problem). :-)  In fact, I think (and have thought) that the light and dark grey and cyan are all too close to each other - anyone object to me replacing the greys w/ orange and lavender?

> What does the 'green' color mean?
> The links says 'Reviewed (needs proof)'? but how does
> one say 'proofed'.

Cyan (if I understand you correctly).

> Also the milestone link from the Front Page does not go
> anywhere:
> http://docs.scipy.org/numpy/Front%20Page/#milestones

Ooops, accidentally broke that editing the page to make the Milestones link more prominent - I'll fix it imminently.

Thanks again,

DG
> 
> Bruce
> 
> 
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 


      


From d_l_goldsmith at yahoo.com  Tue Jun  9 13:41:21 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Tue, 9 Jun 2009 10:41:21 -0700 (PDT)
Subject: [AstroPy] [SciPy-dev] More on Summer NumPy Doc Marathon
Message-ID: <988376.79271.qm@web52101.mail.re2.yahoo.com>


> Also the milestone link from the Front Page does not go
> anywhere:
> http://docs.scipy.org/numpy/Front%20Page/#milestones

Fixed.

DG


      


From sierra_mtnview at sbcglobal.net  Tue Jun  9 23:08:51 2009
From: sierra_mtnview at sbcglobal.net (Wayne Watson)
Date: Tue, 09 Jun 2009 20:08:51 -0700
Subject: [AstroPy] Astrononomy for the PC :(for Python?)
Message-ID: <4A2F23C3.7000105@sbcglobal.net>

Does the book whose title is in Subject have a version for Python?

-- 
           Wayne Watson (Watson Adventures, Prop., Nevada City, CA)

             (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
              Obz Site:  39? 15' 7" N, 121? 2' 32" W, 2700 feet  

                "The zero is something that must be there 
                 in order to say that nothing is there."
                -- Karl Menninger, Number Words and Symbols
 



From sierra_mtnview at sbcglobal.net  Wed Jun 10 07:40:13 2009
From: sierra_mtnview at sbcglobal.net (Wayne Watson)
Date: Wed, 10 Jun 2009 04:40:13 -0700
Subject: [AstroPy] Astrononomy for the PC :(for Python?)
In-Reply-To: <5.2.1.1.2.20090609212947.01c6ff28@rjs.org>
References: <5.2.1.1.2.20090609204204.01def1b8@blue-cove.com>
	<5.2.1.1.2.20090609204204.01def1b8@blue-cove.com>
	<5.2.1.1.2.20090609212947.01c6ff28@rjs.org>
Message-ID: <4A2F9B9D.5090600@sbcglobal.net>

I figured that probably they hadn't used Python in any of their 
editions, but hoped that maybe they or someone had a Python version 
stuck away somewhere. I'm currently borrowing the FORTRAN version of the 
book. It looks to me like that some of the software they provide can be 
found in some math libraries. I see the book has the authors e-mail 
addresses, so I'll contact them directly.

How is it that when you post to this list that I do not see 
astropy at scipy.org in your header?

RJS wrote:
> At 09:21 PM 6/9/2009 -0700, you wrote:
>> The one I refer to is by Montenbruck and Pfleger.
>
> ahh
> have you checked the Google book?
> http://books.google.com/books?id=WDjJIww337EC&dq=Montenbruck+and+Pfleger+pc&p|rintsec=frontcover&source=bl&ots=p8sYkeYhlV&sig=JW|UOvXWOq3t5-Dh3SH1FAAIvEqA&hl=en&ei=hDYvSpyiFpa8swOUkZWwCg|&sa=X&oi=book_result&ct=result&r|esnum=3 
> <http://books.google.com/books?id=WDjJIww337EC&dq=Montenbruck+and+Pfleger+pc&printsec=frontcover&source=bl&ots=p8sYkeYhlV&sig=JWUOvXWOq3t5-Dh3SH1FAAIvEqA&hl=en&ei=hDYvSpyiFpa8swOUkZWwCg&sa=X&oi=book_result&ct=result&resnum=3> 
>
> Page 4 mentions C++, Java, Ada and Fortran.
> No Python came up in the search...
>
> Ray Schumacher
> Programmer/Consultant
> PO Box 8677
> La Jolla, CA 92038-8677
> (858)456-3938
> http://rjs.org/
>

-- 
           Wayne Watson (Watson Adventures, Prop., Nevada City, CA)

             (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
              Obz Site:  39? 15' 7" N, 121? 2' 32" W, 2700 feet  

                "The zero is something that must be there 
                 in order to say that nothing is there."
                -- Karl Menninger, Number Words and Symbols
 



From sontag at stsci.edu  Thu Jun 11 10:49:12 2009
From: sontag at stsci.edu (Chris Sontag)
Date: Thu, 11 Jun 2009 10:49:12 -0400
Subject: [AstroPy] PyRAF v1.8 is now available
In-Reply-To: <49369B20.7090103@stsci.edu>
References: <49369B20.7090103@stsci.edu>
Message-ID: <4A311968.7060209@stsci.edu>

PyRAF v1.8 IS NOW AVAILABLE

The Science Software Branch of the Space Telescope Science Institute 
wishes to announce the availability of PyRAF version 1.8, which includes 
support for Python 2.6.  Since the last major release there have been 
bug-fixes, enhancements, and improvements to running natively on Mac OS 
X.   Documentation, release notes, and download instructions are 
available here:

        http://www.stsci.edu/resources/software_hardware/pyraf

Please direct any questions, comments, or suggestions to "help at stsci.edu".


From tgrav at mac.com  Thu Jun 11 10:55:14 2009
From: tgrav at mac.com (Tommy Grav)
Date: Thu, 11 Jun 2009 10:55:14 -0400
Subject: [AstroPy] Creating Rice compressed fits files
Message-ID: <0934B455-ABA2-4CFF-9FAA-EDCED4436D35@mac.com>

Can anyone give me a short code example of how to save
a fits object I have created using the RICE compression?

Cheers
   Tommy


From jtaylor2 at stsci.edu  Thu Jun 11 11:39:29 2009
From: jtaylor2 at stsci.edu (jtaylor2 at stsci.edu)
Date: Thu, 11 Jun 2009 11:39:29 -0400 (EDT)
Subject: [AstroPy] Creating Rice compressed fits files
Message-ID: <20090611113929.ABD73613@comet.stsci.edu>

Tommy,

    To create a compressed image HDU from scratch, simply construct a CompImageHDU object from an uncompressed image data array and its associated image header.  From there, the HDU can be treated just like any image HDU.

For example if you have an uncompressed HDU with the name uncompHDU you could do the following:

>>> compHDU = pyfits.CompImageHDU(uncompHDU.data, uncompHDU.Header)

Then you can write it out to a file with:

>>> compHDU.writeto('outfile.fits')

The help on CompImageHDU will give you lots of gory details about the CompImageHDU initializer including some options that effect the compression.  Note that RICE is the default compression method used.

>>> help(pyfits.CompImageHDU.__init__)


   I hope this helps,

       Jim T.


From jturner at gemini.edu  Tue Jun 16 21:07:42 2009
From: jturner at gemini.edu (James Turner)
Date: Tue, 16 Jun 2009 21:07:42 -0400
Subject: [AstroPy] JOB: Data Process Developer at the Gemini Observatory in
	Hawaii
Message-ID: <4A3841DE.9090803@gemini.edu>

I just wanted to point out our opening at Gemini North for
developing scientific Python software:

   http://www.gemini.edu/jobs#41
   http://members.aas.org/JobReg/JobDetailPage.cfm?JobID=25672

Note that applications should be submitted as outlined at the
above links and not sent to me personally.

Thanks!

James.



From mperrin at ucla.edu  Wed Jun 24 19:53:27 2009
From: mperrin at ucla.edu (Marshall Perrin)
Date: Wed, 24 Jun 2009 16:53:27 -0700
Subject: [AstroPy] AstroLib vs Astlib vs APLpy vs ...
Message-ID: <A3326D41-3150-4520-A594-329B16B21702@ucla.edu>

Hi all,

I'm a member of that great teeming horde of not-really-using-Python- 
yet astronomers, slowly trying to wean myself from IDL and onto  
Python.  I've written a handful of little things in Python but want to  
dive in fully for my next project. As part of that process, I'm trying  
to figure out what the real must-have list of python modules is for  
everyday astronomical tasks.  In IDL, there's sort of a consensus  
library that most folks use, at least in part: the Goddard IDL Astro  
library, Craig Markwardt's MPFIT library, Dave Fanning's display  
routines, and so on.

It doesn't seem like Python yet has that consensus, once you get much  
beyond the triumvirate of scipy, numpy, & matplotlib.  Am I wrong? As  
far as I can tell there are several different libraries aspiring to be  
"*the*" astronomy library in Python - AstroLib and AstLib both, for  
instance.  You can display nice plots with AstLib.ImagePlots or APLpy,  
manipulate coordinates with AstLib.coords or PyWCS, and so on. Which  
of these should I prefer, as a relative python neophyte? Which have  
the most developer momentum behind them right now?  It's all a bit  
confusing, and I'd rather try to spend my time being confused about my  
science objects rather than my software choices. ;-)

It seems like there was a brief attempt to start a discussion about  
this problem here last year (see http://mail.scipy.org/pipermail/scipy-user/2008-April/016062.html 
  and followups) but as far as I know, nothing really came of that.

I don't expect any easy answers here. I'm just curious to hear what  
'the community' is mostly using these days - if there even is a  
consensus! - and what the recommendations are for someone trying to  
make the big switch away from IDL. Thanks very much!

- Marshall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20090624/639b4b86/attachment.html>

From favilac at astro.uson.mx  Wed Jun 24 20:48:16 2009
From: favilac at astro.uson.mx (Fernando Avila Castro)
Date: Wed, 24 Jun 2009 17:48:16 -0700 (MST)
Subject: [AstroPy] AstroLib vs Astlib vs APLpy vs ...
In-Reply-To: <A3326D41-3150-4520-A594-329B16B21702@ucla.edu>
References: <A3326D41-3150-4520-A594-329B16B21702@ucla.edu>
Message-ID: <alpine.LRH.2.00.0906241746490.31501@localhost.localdomain>



 	The other option is to use IRAF via PyRAF.

 	You can script and use all routine already available for IRAF 
inside Python and mix it with numpy, scipy, Scientific Python, pyfits, 
etc.





------------------------------------------------------------------------------
C.Dr. Fernando A. Avila Castro
Responsable del Observatorio Astronomico
del Centro Ecologico de Sonora
http://www.astro.uson.mx/~favilac


From stefan.schwarzburg at googlemail.com  Thu Jun 25 01:54:37 2009
From: stefan.schwarzburg at googlemail.com (Stefan Schwarzburg)
Date: Thu, 25 Jun 2009 07:54:37 +0200
Subject: [AstroPy] AstroLib vs Astlib vs APLpy vs ...
In-Reply-To: <alpine.LRH.2.00.0906241746490.31501@localhost.localdomain>
References: <A3326D41-3150-4520-A594-329B16B21702@ucla.edu>
	<alpine.LRH.2.00.0906241746490.31501@localhost.localdomain>
Message-ID: <c5726b700906242254o50515e10n36a8c3c75c7875f2@mail.gmail.com>

Hi,
displaying a fits file that includes wcs coordinates has not been easy for a
while, which is the reason why several projects emerged that only deal with
this.
Apart from APLpy and AstLib there is also the Kapteyn package (
http://www.astro.rug.nl/software/kapteyn/).
They are all different though. While APLpy has only one purpose (FITSImage)
AstLib is more complete but mostly for the work that the author had to do.
The kapteyn package is very young but tries to be a more complete wcs
handling library with more advanced features like converting between
projections and so on.
PyRAF sounds great but installing IRAF is not the easiest thing to do.
Note also that you can controll a plain ds9 from python via pysao (
http://code.google.com/p/python-sao/)


But still, you have to find out yourself, I guess...

Cheers,
Stefan


On Thu, Jun 25, 2009 at 02:48, Fernando Avila Castro
<favilac at astro.uson.mx>wrote:

>
>
>        The other option is to use IRAF via PyRAF.
>
>        You can script and use all routine already available for IRAF
> inside Python and mix it with numpy, scipy, Scientific Python, pyfits,
> etc.
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> C.Dr. Fernando A. Avila Castro
> Responsable del Observatorio Astronomico
> del Centro Ecologico de Sonora
> http://www.astro.uson.mx/~favilac <http://www.astro.uson.mx/%7Efavilac>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 
Institut f?r Astronomie und Astrophysik
Eberhard Karls Universit?t T?bingen
Sand 1   -  D-72076 T?bingen
schwarz at astro.uni-tuebingen.de
stefan.schwarzburg at googlemail.com

Tel.: 07071/29-78605
-----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20090625/faf02fe0/attachment.html>

From favilac at astro.uson.mx  Thu Jun 25 02:42:52 2009
From: favilac at astro.uson.mx (Fernando Avila Castro)
Date: Wed, 24 Jun 2009 23:42:52 -0700 (MST)
Subject: [AstroPy] AstroLib vs Astlib vs APLpy vs ...
In-Reply-To: <c5726b700906242254o50515e10n36a8c3c75c7875f2@mail.gmail.com>
References: <A3326D41-3150-4520-A594-329B16B21702@ucla.edu>
	<alpine.LRH.2.00.0906241746490.31501@localhost.localdomain>
	<c5726b700906242254o50515e10n36a8c3c75c7875f2@mail.gmail.com>
Message-ID: <alpine.LRH.2.00.0906242339290.32548@localhost.localdomain>



 	Shameless self-plug :)

 	I have an IRAF installer for Ubuntu LTS here:

  	http://cosmos.astro.uson.mx/~favilac/linastro.html

 	It includes latest IRAF, STSDAS, TABLES, PyRAF, PyWCS plus other 
things. It get the ubuntu packages of pyfits, numpy, etc for dependencies.

 	I'll check pysao to include it in the next version of the 
installer :)



> PyRAF sounds great but installing IRAF is not the easiest thing to do.
> Note also that you can controll a plain ds9 from python via pysao
> (http://code.google.com/p/python-sao/)
>


------------------------------------------------------------------------------
C.Dr. Fernando A. Avila Castro
Responsable del Observatorio Astronomico
del Centro Ecologico de Sonora
http://www.astro.uson.mx/~favilac


From rhook at eso.org  Thu Jun 25 03:17:59 2009
From: rhook at eso.org (Richard Hook)
Date: Thu, 25 Jun 2009 09:17:59 +0200
Subject: [AstroPy] AstroLib vs Astlib vs APLpy vs ...
In-Reply-To: <alpine.LRH.2.00.0906242339290.32548@localhost.localdomain>
References: <A3326D41-3150-4520-A594-329B16B21702@ucla.edu>	<alpine.LRH.2.00.0906241746490.31501@localhost.localdomain>	<c5726b700906242254o50515e10n36a8c3c75c7875f2@mail.gmail.com>
	<alpine.LRH.2.00.0906242339290.32548@localhost.localdomain>
Message-ID: <4A4324A7.9090309@eso.org>

Dear All,

In a similar vein, and also something of a self-plug, I would like to 
mention that at ESO we are working on a new version of
the Scisoft collection (www.eso.org/scisoft). This already contains a 
lot of Python packages (listed at the link given below), as well as 
IRAF/STSDAS and many other things, and for each release we look around 
for updates and additional items to include. So, we will try to add some 
of the new things mentioned here (such as Kapteyn). Suggestions welcome 
- we want to include as much astronomically useful material as is possible!

See: 
http://www.eso.org/sci/data-processing/software/scisoft/Scisoft-contents.html

for a list of current contents. Scisoft is available as a big tar file 
as well as through yum.

The new Scisoft VIII will appear in the late summer (all being well) and 
will be built on Fedora 11.

Cheers, Richard


Fernando Avila Castro wrote:
>  	Shameless self-plug :)
>
>  	I have an IRAF installer for Ubuntu LTS here:
>
>   	http://cosmos.astro.uson.mx/~favilac/linastro.html
>
>  	It includes latest IRAF, STSDAS, TABLES, PyRAF, PyWCS plus other 
> things. It get the ubuntu packages of pyfits, numpy, etc for dependencies.
>
>  	I'll check pysao to include it in the next version of the 
> installer :)
>
>
>
>   
>> PyRAF sounds great but installing IRAF is not the easiest thing to do.
>> Note also that you can controll a plain ds9 from python via pysao
>> (http://code.google.com/p/python-sao/)
>>
>>     
>
>
> ------------------------------------------------------------------------------
> C.Dr. Fernando A. Avila Castro
> Responsable del Observatorio Astronomico
> del Centro Ecologico de Sonora
> http://www.astro.uson.mx/~favilac
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>   



From perry at stsci.edu  Thu Jun 25 08:40:31 2009
From: perry at stsci.edu (Perry Greenfield)
Date: Thu, 25 Jun 2009 08:40:31 -0400
Subject: [AstroPy] AstroLib vs Astlib vs APLpy vs ...
In-Reply-To: <A3326D41-3150-4520-A594-329B16B21702@ucla.edu>
References: <A3326D41-3150-4520-A594-329B16B21702@ucla.edu>
Message-ID: <1142A13C-201C-4CC7-8C60-5BAC19C7295F@stsci.edu>


On Jun 24, 2009, at 7:53 PM, Marshall Perrin wrote:

> Hi all,
>
> I'm a member of that great teeming horde of not-really-using-Python- 
> yet astronomers, slowly trying to wean myself from IDL and onto  
> Python.  I've written a handful of little things in Python but want  
> to dive in fully for my next project. As part of that process, I'm  
> trying to figure out what the real must-have list of python modules  
> is for everyday astronomical tasks.  In IDL, there's sort of a  
> consensus library that most folks use, at least in part: the Goddard  
> IDL Astro library, Craig Markwardt's MPFIT library, Dave Fanning's  
> display routines, and so on.
>
> It doesn't seem like Python yet has that consensus, once you get  
> much beyond the triumvirate of scipy, numpy, & matplotlib.  Am I  
> wrong? As far as I can tell there are several different libraries  
> aspiring to be "*the*" astronomy library in Python - AstroLib and  
> AstLib both, for instance.  You can display nice plots with  
> AstLib.ImagePlots or APLpy, manipulate coordinates with  
> AstLib.coords or PyWCS, and so on. Which of these should I prefer,  
> as a relative python neophyte? Which have the most developer  
> momentum behind them right now?  It's all a bit confusing, and I'd  
> rather try to spend my time being confused about my science objects  
> rather than my software choices. ;-)
>
> It seems like there was a brief attempt to start a discussion about  
> this problem here last year (see http://mail.scipy.org/pipermail/scipy-user/2008-April/016062.html 
>  and followups) but as far as I know, nothing really came of that.
>
> I don't expect any easy answers here. I'm just curious to hear what  
> 'the community' is mostly using these days - if there even is a  
> consensus! - and what the recommendations are for someone trying to  
> make the big switch away from IDL. Thanks very much!

You certainly point to an important issue and I won't say it isn't a  
problem at some level. On the other hand, I see it as a good sign in  
some respects. It wasn't all that long ago that no wcs library was  
available. And now there are too many :-) That's indicative of much  
greater activity in this area and I think that bodes well for the  
future if it means some confusion right now.

I was hoping soon to try and start some effort to try to integrate  
these efforts, if not into common packages, a common place that people  
could obtain them from. I think over time, these different approaches  
will eventually settle on one or some merging of the existing ones  
once there is a chance to see what the merits of the alternative  
approaches are. It's true that this means some annoyance for users in  
not knowing which one they should use for a while or the possibility  
that the final community package may require them to make changes to  
their scripts. Hopefully this situation won't last a very long time  
for wcs packages. But it isn't always a bad thing for two or three  
different approaches to be tried initially.

Perry





From laidler at stsci.edu  Thu Jun 25 10:32:02 2009
From: laidler at stsci.edu (laidler at stsci.edu)
Date: Thu, 25 Jun 2009 10:32:02 -0400 (EDT)
Subject: [AstroPy] AstroLib vs Astlib vs APLpy vs ...
In-Reply-To: <alpine.LRH.2.00.0906241746490.31501@localhost.localdomain>
References: <A3326D41-3150-4520-A594-329B16B21702@ucla.edu>
	<alpine.LRH.2.00.0906241746490.31501@localhost.localdomain>
Message-ID: <20090625103202.ABH15922@comet.stsci.edu>


>
>
> 	The other option is to use IRAF via PyRAF.
>
> 	You can script and use all routine already available for IRAF 
>inside Python and mix it with numpy, scipy, Scientific Python, pyfits, 
>etc.

Speaking as someone who made the IDL->Python switch and had to
learn IRAF along the way for other reasons, I would
*not* recommend that anyone who didn't already know IRAF bother
to learn it at this point. Going straight to Python is a 
MUCH easier learning curve.

cheers,
Vicki Laidler

>
>
>
>
>
>------------------------------------------------------------------------------
>C.Dr. Fernando A. Avila Castro
>Responsable del Observatorio Astronomico
>del Centro Ecologico de Sonora
>http://www.astro.uson.mx/~favilac
>_______________________________________________
>AstroPy mailing list
>AstroPy at scipy.org
>http://mail.scipy.org/mailman/listinfo/astropy


From d_l_goldsmith at yahoo.com  Thu Jun 25 14:44:23 2009
From: d_l_goldsmith at yahoo.com (David Goldsmith)
Date: Thu, 25 Jun 2009 11:44:23 -0700 (PDT)
Subject: [AstroPy] Advice against learning IRAF in favor of learning Python
Message-ID: <30674.90471.qm@web52110.mail.re2.yahoo.com>


> Speaking as someone who made the IDL->Python switch and
> had to
> learn IRAF along the way for other reasons, I would
> *not* recommend that anyone who didn't already know IRAF
> bother
> to learn it at this point. Going straight to Python is a 
> MUCH easier learning curve.
> 
> cheers,
> Vicki Laidler

I assume you mean learning PyRAF (in addition to learning Python) instead of learning IRAF.  But wouldn't one benefit in their use of PyRAF to know "a thing or two" about IRAF?

DG


      


From laidler at stsci.edu  Thu Jun 25 15:03:44 2009
From: laidler at stsci.edu (laidler at stsci.edu)
Date: Thu, 25 Jun 2009 15:03:44 -0400 (EDT)
Subject: [AstroPy] Advice against learning IRAF in favor of learning
 Python
In-Reply-To: <30674.90471.qm@web52110.mail.re2.yahoo.com>
References: <30674.90471.qm@web52110.mail.re2.yahoo.com>
Message-ID: <20090625150344.ABH22645@comet.stsci.edu>



---- Original message ----
>Date: Thu, 25 Jun 2009 11:44:23 -0700 (PDT)
>From: astropy-bounces at scipy.org (on behalf of David Goldsmith <d_l_goldsmith at yahoo.com>)
>Subject: [AstroPy] Advice against learning IRAF in favor of learning Python  
>To: astropy at scipy.org
>
>
>> Speaking as someone who made the IDL->Python switch and
>> had to
>> learn IRAF along the way for other reasons, I would
>> *not* recommend that anyone who didn't already know IRAF
>> bother
>> to learn it at this point. Going straight to Python is a 
>> MUCH easier learning curve.
>> 
>> cheers,
>> Vicki Laidler
>
>I assume you mean learning PyRAF (in addition to learning Python) instead of learning IRAF.  But wouldn't one benefit in their use of PyRAF to know "a thing or two" about IRAF?

Actually, no, I didn't mean learning PyRAF in addition to Python.

PyRAF is an alternative front-end to IRAF: you can use it instead
of the cl. Its purpose in life is pretty much to provide an
improved interface to IRAF tasks _plus_ everything you can get
from Python. Any new non-IRAF functionality being developed
here at STScI that is available through PyRAF is also distributed
separately as part of the stsci_python package.

If you don't need IRAF, then you don't need PyRAF. You can
work with a standard python interpreter, or ipython which a
lot of people prefer (though I don't), and use the various
python packages directly.

I would recommend that anyone who does need to learn IRAF at
this point do so through the PyRAF interface (I found IRAF 
absolutely impenetrable without PyRAF), but anyone who
doesn't need IRAF doesn't need PyRAF either.

cheers,
Vicki Laidler


From jturner at gemini.edu  Thu Jun 25 20:24:20 2009
From: jturner at gemini.edu (James Turner)
Date: Thu, 25 Jun 2009 20:24:20 -0400
Subject: [AstroPy] Advice against learning IRAF in favor of learning
	Python
In-Reply-To: <30674.90471.qm@web52110.mail.re2.yahoo.com>
References: <30674.90471.qm@web52110.mail.re2.yahoo.com>
Message-ID: <4A441534.5010908@gemini.edu>

> I assume you mean learning PyRAF (in addition to learning Python)
> instead of learning IRAF.  But wouldn't one benefit in their use of
> PyRAF to know "a thing or two" about IRAF?

Yeah, as Vicki says, learning IRAF and PyRAF are pretty much the
same thing.

Cheers,

James.


From ppmime at gmail.com  Fri Jun 26 05:35:09 2009
From: ppmime at gmail.com (=?ISO-8859-1?Q?Jose_Miguel_Ib=E1=F1ez?=)
Date: Fri, 26 Jun 2009 11:35:09 +0200
Subject: [AstroPy] PyFits too slow
Message-ID: <bd10af250906260235y12f8abb3nc4c79483bc32e454@mail.gmail.com>

Hello !

I am trying to iterate through the pixels  of  an FITS image read previusly
with PyFits,
but it is too slow (more that 1CPU minute), so my question is if is there
any other way to do that in a
more efficient/fast  way.

That's the code I'm using:
------------------------------------------------------------------
f=pyfits.open('/tmp/c1.fits',memmap=1)
b=numpy.zeros([2048,2048],dtype='float32')
cdata=f[0].data.copy()
f.close()
print 'start loop...'
for i in range(0,2048):
    for j in range(0,2048):
        if cdata[i,j]<1 or cdata[i,j]>100000:
            b[i,j]=1


----------------------------------------------------------------

Any idea ?

Thanks very much,
JM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20090626/09afe19e/attachment.html>

From Johann.COHEN-TANUGI at LPTA.in2p3.fr  Fri Jun 26 05:32:30 2009
From: Johann.COHEN-TANUGI at LPTA.in2p3.fr (Johann Cohen-Tanugi)
Date: Fri, 26 Jun 2009 11:32:30 +0200
Subject: [AstroPy] PyFits too slow
In-Reply-To: <bd10af250906260235y12f8abb3nc4c79483bc32e454@mail.gmail.com>
References: <bd10af250906260235y12f8abb3nc4c79483bc32e454@mail.gmail.com>
Message-ID: <4A4495AE.2040503@lpta.univ-montp2.fr>

this is very very bad : have a look at the numpy tutorials or user's 
guide. You are not making use of vectorization....

Johann

Jose Miguel Ib??ez wrote:
> Hello !
>
> I am trying to iterate through the pixels  of  an FITS image read 
> previusly with PyFits,
> but it is too slow (more that 1CPU minute), so my question is if is 
> there any other way to do that in a
> more efficient/fast  way.
>
> That's the code I'm using:
> ------------------------------------------------------------------
> f=pyfits.open('/tmp/c1.fits',memmap=1)
> b=numpy.zeros([2048,2048],dtype='float32')
> cdata=f[0].data.copy()
> f.close()
> print 'start loop...'
> for i in range(0,2048):
>     for j in range(0,2048):
>         if cdata[i,j]<1 or cdata[i,j]>100000:
>             b[i,j]=1
>
>
> ----------------------------------------------------------------
>
> Any idea ?
>
> Thanks very much,
> JM
> ------------------------------------------------------------------------
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>   


From ppmime at gmail.com  Fri Jun 26 07:10:30 2009
From: ppmime at gmail.com (=?ISO-8859-1?Q?Jose_Miguel_Ib=E1=F1ez?=)
Date: Fri, 26 Jun 2009 13:10:30 +0200
Subject: [AstroPy] PyFits too slow
In-Reply-To: <8798EC5E-7F8D-407C-B5D7-D46533A0EC01@astro.physik.uni-goettingen.de>
References: <bd10af250906260235y12f8abb3nc4c79483bc32e454@mail.gmail.com>
	<4A4495AE.2040503@lpta.univ-montp2.fr>
	<8798EC5E-7F8D-407C-B5D7-D46533A0EC01@astro.physik.uni-goettingen.de>
Message-ID: <bd10af250906260410r4bff59cei1646a8668c708e88@mail.gmail.com>

Great !!! now it is really fast and powerful !!
I will follow your advices and read the docs and tutorials.

Thanks !


2009/6/26 Derek Homeier <derek at astro.physik.uni-goettingen.de>

> On 26 Jun 2009, at 11:32, Johann Cohen-Tanugi wrote:
>
>  this is very very bad : have a look at the numpy tutorials or user's
>> guide. You are not making use of vectorization....
>>
>> Johann
>>
>> Jose Miguel Ib??ez wrote:
>>
>>> Hello !
>>>
>>> I am trying to iterate through the pixels  of  an FITS image read
>>> previusly with PyFits,
>>> but it is too slow (more that 1CPU minute), so my question is if is
>>> there any other way to do that in a
>>> more efficient/fast  way.
>>>
>>> That's the code I'm using:
>>> ------------------------------------------------------------------
>>> f=pyfits.open('/tmp/c1.fits',memmap=1)
>>> b=numpy.zeros([2048,2048],dtype='float32')
>>> cdata=f[0].data.copy()
>>> f.close()
>>> print 'start loop...'
>>> for i in range(0,2048):
>>>   for j in range(0,2048):
>>>       if cdata[i,j]<1 or cdata[i,j]>100000:
>>>           b[i,j]=1
>>>
>>
> Correct; basically the numpy way to achieve what you want to do would look
> like
>
> b[ (cdata<1) | (cdata>1.e5) ] = 1
>
> and should take fractions of a second. As Johann said, read the tutorials
> to get
> familiar with the basic operations.
>
> Cheers,
>                                                                Derek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20090626/63d0b9d2/attachment.html>

From jh at physics.ucf.edu  Fri Jun 26 21:58:54 2009
From: jh at physics.ucf.edu (Joe Harrington)
Date: Fri, 26 Jun 2009 21:58:54 -0400
Subject: [AstroPy] AstroLib vs Astlib vs APLpy vs ...
In-Reply-To: <mailman.3.1245949202.8183.astropy@scipy.org>
	(astropy-request@scipy.org)
References: <mailman.3.1245949202.8183.astropy@scipy.org>
Message-ID: <wl8k52ybfoh.fsf@glup.physics.ucf.edu>

There *is* a central place to list all relevant packages: the
scipy.org list of Topical Software, in the astronomy section:

http://scipy.org/Topical_Software#head-4891fc4038123c6a923398225a728ec92ddb2780

If you just go to http://scipy.org/Topical_Software and click on
Astronomy, you get there, too.

Don't forget Russell Owen's excellent interface to DS9, which does not
do the interpolation of numdisplay nor require manual specification of
separate fifo ports on multiuser systems.

I would favor some kind of universal collection of utility software,
but there were problems with the social and release organizations of
IDLastro and SciPy that we should try to avoid.  For example, how
should we fund it, how should we review contributions, should we
choose just one approach to each problem or include multiple
solutions, should we include large packages, should we have a sandbox,
how will we coordinate releases, how do we enforce good documentation,
etc.  Already, we have several candidate collections, none of which,
to my knowledge, has gotten the community behind it nor answered any
of the "thinking big" questions.  I think we ought to do that before
moving forward with a collection.

But, I also think everyone must play in a "sandbox"-type testing
ground (or release independently) for at least a year before getting
accepted into the collection package.  To get out (and into the
collection) you must demonstrate: broad adoption for your package,
stability, maturity (i.e., a relatively slow release cycle compatible
with the big collection), reliability (low numbers of bug reports),
top-quality reference and user docs, and a commitment to long-term
maintenance.

So, people should aggressively develop software and post notices of
their existence both here on this list and in Topical Software.  The
key to a well-accepted collection will be a lot of well-tested and
well-discussed software.

Meanwhile, let's talk about a sort of charter for this collection
online, and wrap up with some decision-making at an astronomy BoF at
SciPy 2009 in August.  We can skype in anyone who can't make it.

--jh--