astropy.idl ?

[Tom Aldcroft]

It seems that, for better or worse, many astronomers would like Python
versions of the IDL astronomy library routines. The AstroPy project
has a vision of replacing most of that functionality with a Pythonic
infrastructure that will be much better, and I am 100% committed to
that vision.

However, in the interest of being pragmatic I want to open a
discussion about including a subpackage of astropy that is devoted to
straight ports of IDL astrolib routines to Python. There are some
features of this approach:

- Doing a straight port of many idlastro routines can be relatively fast.
- Such ports can often be done by interested astronomers who don't
have as much Python programming expertise.
- The astropy project can potentially open up to a wider community of
developers and get momentum and exposure.
- We can encourage idlastro ports to uphold the coding and testing
standards for the rest of astropy.
- Hopefully there will quickly be a core astropy that will provide
enough functionality that some idlastro ports would just be thin
wrappers.
- This might lower the entry barrier to Python for the IDL-using
segment of the community.

I don't expect too many of the current astropy developer community
thus far to participate in such ports, but the idea is to advertise to
a broad audience that there is a well-recognized place where they can
end up. Prasanth has already done a couple (at a standard that
exceeds what the average astronomer would provide) and it would be
good to have them incorporated somewhere in astropy.

There is the downside of officially endorsing a stop-gap measure that
doesn't adhere to our vision of astronomy software for the future.
Comments? I'm not strongly advocating this idea, but thought it
should at least be discussed.

- Tom

[James Turner]

> There is the downside of officially endorsing a stop-gap measure that
> doesn't adhere to our vision of astronomy software for the future.
> Comments? I'm not strongly advocating this idea, but thought it
> should at least be discussed.

I'd say (as a non-IDL user) that it makes sense with a couple of
restrictions that code in other AstroPy modules should avoid depending
on the IDL compatibility module (if possible) and ideally the IDL
compatibility routines will get built on top of native Pythonic
functionality.

I'm pretty sure we shouldn't use the acronym idl though, as it will
be a trade mark, but something else like "dl" or "compatibility" or
"foreign" or whatever someone comes up with that's a bit more
ergonomic.

James.

[Wolfgang Kerzendorf]

Hi Tom,

I think that might be a good idea, however I see some issues:

In my opinion our first priority should be making an excellent astronomy package (maybe strife to be the best ;-)) and not to convert IDL users to python.

That's why I suggest to provide these IDL ports to live externally in an affilliated astropy package and as Tom said to advertise this and incorporate existing work in this.

My 2 cents,
Wolfgang

[Kacper Kowalik]

W dniu 18.10.2011 20:30, Tom Aldcroft pisze:

Why do you want to duplicate efforts that are already being made? [1]
AFAIR gdl can be called as python module. Channeling energy of people
wanting to port IDL astro to GDL and then making sure AstroPy interacts
with it smoothly would be IMO much more beneficial.
Cheers,
Kacper

[1] http://gnudatalanguage.sourceforge.net/

[Tom Aldcroft]

I suppose pydl would work. Projects like gdl and pdl have managed to
avoid the RSI lawyers with a few well placed disclaimers, although
neither of those *rhymes* with IDL. :-)

- Tom

[Victoria G. Laidler]

Kacper Kowalik wrote:
>
> Why do you want to duplicate efforts that are already being made? [1]
> AFAIR gdl can be called as python module. Channeling energy of people
> wanting to port IDL astro to GDL

What kind of effort is being made here? Is there a website or pointer to
that specific effort?

> and then making sure AstroPy interacts
> with it smoothly would be IMO much more beneficial.
> Cheers,
> Kacper
>
> [1] http://gnudatalanguage.sourceforge.net/
>

The website claims that GDL can be called from Python, but the user's
guide for that functionality looks like it has not yet been written.

Has anybody actually got any experience with using GDL from Python that
they can share?

As to the meta-question: I've already migrated from IDL to Python, and
there are Astron routines that I miss. I would MUCH rather have Python
equivalents of those Astron libraries as part of Astropy, than have to
install yet another package, and possibly have to dust my IDL skills
back off (and upgrade them to GDL skills) in order to troubleshoot problems.

[James Turner]

> I suppose pydl would work. Projects like gdl and pdl have managed to
> avoid the RSI lawyers with a few well placed disclaimers, although
> neither of those *rhymes* with IDL. :-)

There was already a pyDL though, which I think actually wraps IDL
directly:

http://sourceforge.net/projects/pydl-bridge/

Then apparently there was an old proposal for another PyDL that's
"something completely different":

http://www.prescod.net/pytypes/

[Kacper Kowalik]

W dniu 18.10.2011 21:01, Victoria G. Laidler pisze:

> Kacper Kowalik wrote:
>>
>> Why do you want to duplicate efforts that are already being made? [1]
>> AFAIR gdl can be called as python module. Channeling energy of people
>> wanting to port IDL astro to GDL
> What kind of effort is being made here? Is there a website or pointer to
> that specific effort?

I meant the effort of creating python bindings for IDL (in this case
software that's compatible with IDL) or rewriting it from scratch,
within AstroPy.

>> and then making sure AstroPy interacts
>> with it smoothly would be IMO much more beneficial.
>> Cheers,
>> Kacper
>>
>> [1] http://gnudatalanguage.sourceforge.net/
>>
> The website claims that GDL can be called from Python, but the user's
> guide for that functionality looks like it has not yet been written.

Yeah, user guide is kinda outdated. But it really works, though syntax
is a nightmare:

>>> import GDL
>>> x = GDL.function("findgen", 10 )
>>> GDL.pro("plot",x)

> Has anybody actually got any experience with using GDL from Python that
> they can share?
>
> As to the meta-question: I've already migrated from IDL to Python, and
> there are Astron routines that I miss. I would MUCH rather have Python
> equivalents of those Astron libraries as part of Astropy, than have to
> install yet another package, and possibly have to dust my IDL skills
> back off (and upgrade them to GDL skills) in order to troubleshoot
> problems.

Both Astron FAQ[1] and gdl forums[2] give the impression that it *may*
work out-of-the-box. I must admit I haven't checked that, I don't even
use native IDL's Astron.

[1] http://idlastro.gsfc.nasa.gov/idlfaq.html#A2
[2]
http://sourceforge.net/projects/gnudatalanguage/forums/forum/338691/topic/4388702

Cheers,
Kacper

[Peter Erwin]

On Oct 18, 2011, at 9:54 PM, Kacper Kowalik wrote:

> W dniu 18.10.2011 21:01, Victoria G. Laidler pisze:
>> Kacper Kowalik wrote:
>>>
>>> Why do you want to duplicate efforts that are already being made? [1]
>>> AFAIR gdl can be called as python module. Channeling energy of people
>>> wanting to port IDL astro to GDL
>> What kind of effort is being made here? Is there a website or pointer to
>> that specific effort?
> I meant the effort of creating python bindings for IDL (in this case
> software that's compatible with IDL) or rewriting it from scratch,
> within AstroPy.

But that's not what Tom was proposing, as far as I can tell; he was simply
suggesting creating instances of Python code -- e.g., individual functions
(presumably in pure Python) which had the same basic user interfaces
(same or similar function name, same or similar ordering of inputs,
same or similar keywords, and same or similar output) as well-known and
popular IDL astronomy routines. That's nothing like "python bindings for IDL".

cheers,

Peter

=============================================================
Peter Erwin Max-Planck-Insitute for Extraterrestrial
er...@mpe.mpg.de Physics, Giessenbachstrasse
tel. +49 (0)89 30000 3695 85748 Garching, Germany
fax +49 (0)89 30000 3495 http://www.mpe.mpg.de/~erwin

[Victoria G. Laidler]

Kacper Kowalik wrote:
> W dniu 18.10.2011 21:01, Victoria G. Laidler pisze:
>
>> Kacper Kowalik wrote:
>>
>>> Why do you want to duplicate efforts that are already being made? [1]
>>> AFAIR gdl can be called as python module. Channeling energy of people
>>> wanting to port IDL astro to GDL
>>>
>> What kind of effort is being made here? Is there a website or pointer to
>> that specific effort?
>>
> I meant the effort of creating python bindings for IDL (in this case
> software that's compatible with IDL) or rewriting it from scratch,
> within AstroPy.
>

Sorry, let me clarify my question. You asked "why duplicate existing
effort", and stated that there were already people who want to convert
*the IDL astro library* to GDL.

My question was, who are those people who want to port the IDL astro
library to GDL? What kind of effort are they already making? Is there
really an active project to convert the IDL astro library to GDL that
has something to show for itself now?

>>> and then making sure AstroPy interacts
>>> with it smoothly would be IMO much more beneficial.
>>> Cheers,
>>> Kacper
>>>
>>> [1] http://gnudatalanguage.sourceforge.net/
>>>
>>>
>> The website claims that GDL can be called from Python, but the user's
>> guide for that functionality looks like it has not yet been written.
>>
>
> Yeah, user guide is kinda outdated. But it really works, though syntax
> is a nightmare:
>
>
>>>> import GDL
>>>> x = GDL.function("findgen", 10 )
>>>> GDL.pro("plot",x)
>>>>

Incorrect documentation and nightmarish syntax are two more reasons to
just go ahead and write it for IDL. :)

>
>
>> Has anybody actually got any experience with using GDL from Python that
>> they can share?
>>
>> As to the meta-question: I've already migrated from IDL to Python, and
>> there are Astron routines that I miss. I would MUCH rather have Python
>> equivalents of those Astron libraries as part of Astropy, than have to
>> install yet another package, and possibly have to dust my IDL skills
>> back off (and upgrade them to GDL skills) in order to troubleshoot
>> problems.
>>
>
> Both Astron FAQ[1] and gdl forums[2] give the impression that it *may*
> work out-of-the-box. I must admit I haven't checked that, I don't even
> use native IDL's Astron.
>
> [1] http://idlastro.gsfc.nasa.gov/idlfaq.html#A2
> [2]
> http://sourceforge.net/projects/gnudatalanguage/forums/forum/338691/topic/4388702
>

Thanks for the pointers.

Vicki

[Kacper Kowalik]

W dniu 18.10.2011 22:15, Victoria G. Laidler pisze:

> Kacper Kowalik wrote:
>> W dniu 18.10.2011 21:01, Victoria G. Laidler pisze:
>>
>>> Kacper Kowalik wrote:
>>>
>>>> Why do you want to duplicate efforts that are already being made? [1]
>>>> AFAIR gdl can be called as python module. Channeling energy of people
>>>> wanting to port IDL astro to GDL
>>> What kind of effort is being made here? Is there a website or pointer to
>>> that specific effort?
>>>
>> I meant the effort of creating python bindings for IDL (in this case
>> software that's compatible with IDL) or rewriting it from scratch,
>> within AstroPy.
>>
>
> Sorry, let me clarify my question. You asked "why duplicate existing
> effort", and stated that there were already people who want to convert
> *the IDL astro library* to GDL.

To clarify myself, I thought the underlying task is to be able to call
Astron routines directly from Python. Initial proposal was to rewrite
them into pure Python, which admittedly if it was done would certainly
be the most convient for end-users, though it would require a *lot* of
work. So I've asked why do you want to duplicate work if it's already
possible via GDL's python bindings. Then you'll be using well tested,
original code base of IDL Astron instead of writting it from the scratch.

> My question was, who are those people who want to port the IDL astro
> library to GDL? What kind of effort are they already making? Is there
> really an active project to convert the IDL astro library to GDL that
> has something to show for itself now?

There'll be *no* conversion needed if GDL does it job right. It aims to
be compatible with IDL-6.x in 100%.

Cheers,
Kacper

[Kacper Kowalik]

W dniu 18.10.2011 22:06, Peter Erwin pisze:

>
> On Oct 18, 2011, at 9:54 PM, Kacper Kowalik wrote:
>
>> W dniu 18.10.2011 21:01, Victoria G. Laidler pisze:
>>> Kacper Kowalik wrote:
>>>>
>>>> Why do you want to duplicate efforts that are already being made? [1]
>>>> AFAIR gdl can be called as python module. Channeling energy of people
>>>> wanting to port IDL astro to GDL
>>> What kind of effort is being made here? Is there a website or pointer to
>>> that specific effort?
>> I meant the effort of creating python bindings for IDL (in this case
>> software that's compatible with IDL) or rewriting it from scratch,
>> within AstroPy.
>
> But that's not what Tom was proposing, as far as I can tell; he was simply
> suggesting creating instances of Python code -- e.g., individual functions
> (presumably in pure Python) which had the same basic user interfaces
> (same or similar function name, same or similar ordering of inputs,
> same or similar keywords, and same or similar output) as well-known and
> popular IDL astronomy routines. That's nothing like "python bindings for IDL".

Maybe I was unclear, but I meant that by "rewriting it from scratch
within AstroPy". Second option, which wasn't mentioned by Tom, that I
was referring to in the first part is to actually "reuse" IDL Astron
directly by either calling IDL or GDL via some sort of Python bindings.
Sorry for the mental shortcuts :(
Cheers,
Kacper

[Thomas Robitaille]

I think Tom's original idea is worth considering, and the way I see it
if it gets done is that astropy.idl would have thin wrappers to numpy,
scipy, and astropy functionality with the IDL astrolib function names
and arguments.

One argument against just seeing astropy.idl as a set of bindings to
IDL/GDL is that this requires IDL/GDL to be installed. One might
envisage the case where someone just wants to have Python installed,
but coming from an IDL background, might want to be able to use
astropy functionality via a familiar API.

An alternative to this altogether is to have a section of the
documentation (this was discussed at the meeting) with an astrolib to
astropy conversion table (like
http://www.astrobetter.com/wiki/tiki-index.php?page=Python+Switchers+Guide)
which gets built up as the astropy package grows. This could also keep
track of astrolib functions that do *not* have an astropy/scipy
equivalent, and would be a good way for us to know what areas are
lacking for astronomers coming from IDL.

Cheers,
Tom

[Tom Aldcroft]

Just to be clear, my original intent was indeed the idea of
"crowd-sourcing" the task of directly rewriting IDL astro routines in
Python. As Kelle said, in many cases this is relatively
straightforward and can be done by anyone interested in contributing
to Python for astronomy. I think it's useful to have this under the
umbrella of AstroPy both for quality control (there is a pool of
expert code reviewers and documentation standards) and as an incentive
for non-expert coders (i.e. most astronomers, esp. undergraduates etc)
to contribute to a well-established project.

- Tom

[Victoria G. Laidler]

Tom Aldcroft wrote:
> Just to be clear, my original intent was indeed the idea of
> "crowd-sourcing" the task of directly rewriting IDL astro routines in
> Python. As Kelle said, in many cases this is relatively
> straightforward and can be done by anyone interested in contributing
> to Python for astronomy. I think it's useful to have this under the
> umbrella of AstroPy both for quality control (there is a pool of
> expert code reviewers and documentation standards) and as an incentive
> for non-expert coders (i.e. most astronomers, esp. undergraduates etc)
> to contribute to a well-established project.

I agree, especially if complemented by maintaining the kind of
conversion table that Thomas Robitaille mentioned earlier.

Another potential upside: _how_ many years have we been saying "oh we
should have IDL Astron for python"? It would be a credibility booster to
actually accomplish a significant portion of that.

The potential downside, of ending up with a collection of individual
routines instead of a healthy infrastructure, could be mitigated by a
commitment to rework as necessary once that infrastructure actually exists.

[Wolfgang Kerzendorf]

Hey Guys,

I think all of these things a good, meaning a collection of utensils for IDL-Python (including Prasanth's efforts, Vicki's efforts, etc... and GDL PyDL stuff), but I think it should live in an affiliated package (which are mentioned on AstroPy's website and can be installed with Erik T's installer afaik). That way we can keep the core very clean with code that has been triple checked and is up to scratch in coding guidelines and documentation and we can still encourage users - that don't write perfectly PEP 8 compliant code (including me most of the time) - to contribute to this affiliated package.

Cheers
Wolfgang

[Matt Davis]

I would definitely prefer just straight rewriting routines in Python. The point of having such translated routines is to woo people to AstroPy and that will be more difficult if we ask them to install even more things.

If we maintain an idl -> astropy conversion table and allow people to add things like a wish list that could definitely give us some direction. As translations are added to astropy we will probably identify a lot of overlap and generally useful ideas that we can add to core astropy and share between translated and new utilities.

I can think of reasons not to include idl translations in AstroPy but not so much because of coding style: an experienced developer can always help someone get code up to spec. Rather, it's a bit undesirable to have a pile of code sitting in the same area that doesn't share a common purpose. On the other hand, having the translations in core astropy will make it easier for developers to hollow out the translations, moving the functionality into its logical place within astropy and leaving behind a tiny wrapper, or even deleting that wrapper and updating the idl -> astropy table.

Best,

Matt

[Erik Tollerud]

I agree that it makes a lot of sense to provide this as an affiliated
package that implements everything in python. We definitely *don't*
want this to take much energy away from building the more pythonic
version of all of the tools, but my experience porting reasonably
simple IDL routines has been that its usually very straightforward as
long as you're willing to compromise where necessary (e.g. it can't
look *exaclty* like the IDL procedure because of the language
construct that don't necessarily exist in python). We shouldn't
necessary plan on porting all of astron or whatever, but just those
that people are really wanting.

Along those lines, I also definitely like Matt's idea of maintaining a
list of those procedures implemented and those that people want,
probably on the wiki for the affiliated package.

Another thing we should definitely do in this package is clearly say
in the docstrings (and perhaps, even as a message that pops up when
you use the routine or something?) the "better" may to do a given task
from the more pythonic interface. That way people can use what they're
used to, but can see that there are more efficient ways of doing it if
they're willing to take the time to dig into the pythonic side a bit
more. That will also encourage us to actually get the python side of
those things done - and in some (probably most, when I think about it)
cases the IDL version can just be a wrapper around a more pythonic
version that's in astropy.

--
Erik Tollerud

[Rene]

Hi everyone,

Here's my two cents about the whole pyIDL thing. Some time ago, my
colleague Mubdi Rahman and I started the pyAstrolib project (http://
pyastrolib.sourceforge.net). The main goal was to port the nice IDL
Astrolib functionalities to Python. The short version of the long
story is that we've done some work but things progressed slowly simply
because we are busy with other things.

Initially, we wanted to have a legacy project where things would
simply reproduce Astrolib and then we would add new routines. Since
IDL and Python have similar syntax it is indeed relatively easy to
rewrite the code for Python (though messy sometimes because of the
different behaviour of indexing and the way certain numpy/scipy
functions ares compared to their IDL "equivalent"). As I was coding
though I realized how clunky the IDL Astrolib routines are (no offense
to those who wrote them, you'll see why in a second). There are two
main reasons:
1. Most of IDL Astrolib stuff was actually written in the old Fortran
way: "for loops" everywhere, very little use of matrix algebra, etc.
2. The IDL Astrolib routines are very "procedural". It's not rare to
find a routine which uses mutually exclusive optional keywords.

So as I was rewriting some of the routines I came up to the conclusion
that it was a waste of time to try to duplicate and it would simply be
bad to perpetuate the "non-modern" behaviours. Instead, I decided to
use IDL's Astrolib as an inspiration to write more modern routines; it
has nice core functions but needs to be modernized. Say, I rewrote the
"find" routine in the photometry package following the IDL's algorithm
philosophy but making use numpy/scipy and got rid of all the junk
around. A lot of stuff is readily obsolete because of pywcs and pyfits
anyways.

If some people want to do an exact duplicate of IDL's Astrolib for
Python, they are certainly free to do so and this is good for them.
However, I would find it more productive to think twice about it. I
would argue that one will not switch from IDL to Python if the exact
same thing exist in Python. If so, why bother since their IDL programs
will need to be rewritten anyways, if only for the fact that
dimensions in arrays are inverted. In my opinion, what stops someone
from switching to Python is the lack of basic core functions. Ex:
someone wanting to locate point sources on an image, perform simple
aperture photometry at their locations, etc.

Again, if some people want to do a legacy affiliated package, fine.
Moving forward, my goal is to take the list of IDL's Astrolib
routines, slash the ones that are obsolete because they already exist
or are not required anymore, keep the good ones and rewrite them in a
modern way that integrates with the other available packages like
scipy/numpy/pyfits/pywcs and make their implementation more modern.
The great improvement of IDL's Astrolib over previous work was the
modular approach. Ex: for photometry is doesn't try to take your data
from the telescope and run a pipeline all the way to the latex table
for your paper; there's a find, aper, sky, etc. Then one can build
nice pipelines out of these tools. We should keep that in mind.

Last thing, I have interest in leading a photometry development group,
hopefully to be part of the core package.

Cheers

Rene Breton

[Tom Aldcroft]

Hi Rene,

Thanks for your nice commentary, this is very useful for the
discussion and I basically agree with most of your points. Just
thought I would add that next week I am meeting with a long-time IDL
astronomy user who is quite interested in transitioning to Python but
hasn't found a way to replace the tools he depends on. He was really
excited when I mentioned the AstroPy project, so we'll see what
perspective he can bring. I'll report here on the results.

- Tom

[Peter Erwin]

Hi Rene,

I think the idea, as I understood it, was to duplicate some of the more
useful functionality -- keeping at least some of the same interface and
visible behavior -- of IDL astronomy routines, without necessarily trying
to duplicate the *internal* structure of individual functions and procedures.

So if there's a useful IDL function FROBLE(x, y, z) which returns a floating-point
value, what would be useful is a Python function Froble(x, y, z) returning a
float; as long as the algorithm works properly and the output is correct, there's
no need for the internal code to be at all similar.

(This is, I think, largely what you're suggesting; I'm merely pointing out that
it's probably what people had in mind already.)

(Of course, there's not necessarily anything wrong with someone doing a more
literal translation of a function/procedure, making sure it passes the necessary
tests, and then refactoring to be more Pythonic; I've done this with some of my
colleague's IDL code, and with some of my old IDL code for dealing with
ellipse-fit tables from IRAF.)

I think your point about the modularity and composibility of the IDL tools is an
excellent one, by the way, and I agree that we should keep it in mind.

cheers,

Peter

=============================================================

[Marshall Perrin]

First, let me say that I wish I could've joined you all at the CfA meeting, but alas I had one of those pesky science conferences the same week... :-)

Now, on the topic of python/idl wrappers:

I'd like to draw a distinction between two kinds of IDL code we might want to provide Python reimplementations of:
- the core IDL language (e.g. findgen, strpos, bytscl, svdc, etc, as provided by ITT). Python equivalents of these could be useful to a broad audience beyond just astronomers, and could perhaps be packaged separately. These also usually have pretty simple calling conventions.
- and the IDL astronomy library itself. These functions are of course mostly useful to us, the APIs are often complicated and not always all that consistent.
When I was first making the switch from IDL to Python a couple years ago, I ended up writing a handful of routines in both categories. The idl base routines are particularly useful in that they significantly ease direct ports of IDL code to Python, potentially providing a quick route to functional if unpythonic code. But these days I don't use any of that code any more, so in retrospect it feels a bit like wasted effort.

There's also the i2py IDL to Python code converter, which I experimented with for a while. The project appears to be defunct, and while I hacked on a bit to get it running against numpy instead of numeric, I never went very far with it. It was useful for doing some basic code conversions but a large amount of manual cleanup was still needed to get any moderately complicated algorithm ported properly. I point this out just so that folks are aware this tool exists, not because I necessarily think it's a useful approach.

In any case, any systematic attempt to provide Python equivalent to IDL routines needs to figure out how to address a couple tricky issues, including but not limited to
1) Array indexing, given the opposite conventions of IDL and Python for axis ordering. Should idl.max( some_array, dimension=2) return the maximum along the axis that IDL considers axis 2 (which would be the fastest-varying axis for e.g. a 3D cube), or the axis that Python considers axis 2 (the slowest axis, for that example)? This is a trivial example, and at first it seems more straightforward to have the IDL compatibility code use the IDL convention, but this (a) leads to code with lots of axis order swapping that can become convoluted and hard to follow, and (b) makes it harder to use this IDL compatibility layer as a bridge toward a pure Python implementation.

2) how to handle IDL's use of optional output parameters. Probably the best is to just return tuples - but should the code always return the full set of potential return parameters, or should there be a boolean parameter to indicate whether to return the full set or a smaller subset?

Based on my experiences trying to deal with these during my own IDL to Python switch, I pretty quickly gave up. It was just too unsatisfying and too many things ended up being kludges around the differences in the languages. So my recommendation is that the community *NOT* devote any significant effort to near-API-compatible Python implementations for anything beyond the most trivial cases.

Rather, I think what's most important is having functional equivalents with a more pythonic API, and a cross-reference list in the style of the 'numpy for IDL users' guide but with higher level functionality. I.e. "for readfits instead use pyfits.getdata, for aper.pro use aperturephotom.py (or whatever)." There's a lot of functionality in the IDL astro library which is not yet available in Python as far as I know, for instance the hextract/hrot/hrebin functions for FITS manipulation with WCS. I think if we can provide a lookup table from IDL functions into Pythonic semantic equivalents, that will ultimately be much more useful than trying to build a set of syntactic equivalents. I'm not opposed to translation wrappers for some simple functions, but as soon as it becomes un-obvious how to convert an IDL function call into Python, then you should stop trying and just design a new Pythonic function call (or class) that gets the job done right.

- Marshall

[Matt]

This is why the AstroBetter idl -> python table is such a great idea. For a lot of routines there is probably a short list of python + numpy + scipy + matplotlib + astropy utilities that does the same thing, and we don't need to write an actual script, just point people to the right stuff, maybe provide examples. It could even be useful for getting people started in Python. Give a dude a fish...

- Matt

[Rene Breton]

Hi Tom,

This will be interesting to get you friends feedback. On my side, I was an IDL user before and other friends who use IDL told me the same thing: if they can find similar functionalities they will switch. Those people don't want something litteral and exactly the same; they want to have easy to use tools that can do the same type of stuff (like finding point sources, computing approximate astrometry solution from 3 x,y and 3 ra,dec points, etc.). As long as things are modular and intuitive to use, I think we're on the right track.

Let us know what your friend has to say.

Cheers,

Rene

[Rene Breton]

Matt,

I totally agree with you! Having a nice table with the list of IDL Astrolib routines and their python equivalent (numpy/scipy/pyfits/pywcs/astropy) is definitely something we should do, regardless of what happens with pyidl/whatver_it_is_called. It's a nice quick view on how to do things.

Rene

[Rene Breton]

Hi Marshall,

- the core IDL language (e.g. findgen, strpos, bytscl, svdc, etc, as provided by ITT). Python equivalents of these could be useful to a broad audience beyond just astronomers, and could perhaps be packaged separately.  These also usually have pretty simple calling conventions.

I agree this is an issue and there are a bunch of useful things out there. To me, these could go in some miscellaneous subpackage and they don't clearly belong to a particular subpackage (like astropy.misc or whatever). Eventually and ideally though, if these are not too astronomy focused, they should just make their way to numpy/scipy. In which case, they could become deprecated and wrapping to their new location in numpy/scipy.

I think there will be general things that will never be useful to other people than astronomers. For instance, I just wrote a routine that matches some (x1,y1) list to a (x2,y2) list, and returns the indices of 1 and 2 for the nearest matches whose distance r is less than some threshold. That is useful to pair catalog entries for us astronomers and even though it's kind of general, I don't think the average python community would really want that.

 

1) Array indexing, given the opposite conventions of IDL and Python for axis ordering. Should idl.max( some_array, dimension=2) return the maximum along the axis that IDL considers axis 2 (which would be the fastest-varying axis for e.g. a 3D cube), or the axis that Python considers axis 2 (the slowest axis, for that example)? This is a trivial example, and at first it seems more straightforward to have the IDL compatibility code use the IDL convention, but this (a) leads to code with lots of axis order swapping that can become convoluted and hard to follow, and (b) makes it harder to use this IDL compatibility layer as a bridge toward a pure Python implementation.

Here to me it's pretty simple. Anything that goes in astropy's core should be pythonic. Array indexing is what it is. The first element of an array is 0, the last dim-1. The axis indexing is pythonic as well. Otherwise, things just become a mess and you end up crashing space probes on Mars because some people still use obsolete imperial units instead of SI ;-)

Imagine you do something with this IDL and pass the "old" dimension = 2, but then you play some more with the array with numpy... This just becomes confusing. In separate packages, people are free to do whatever they want, but I'd certainly recommend they follow Python's.

 

2) how to handle IDL's use of optional output parameters. Probably the best is to just return tuples - but should the code always return the full set of potential return parameters, or should there be a boolean parameter to indicate whether to return the full set or a smaller subset?

Interesting question. I think we could adopt numpy/scipy's philosophy here. Take the scipy.optimize.fmin for example. You have the "full_output" boolean switch to return either just the actual best-fit parameters, or the full details. In most cases, it could work the same. Routines return what they are expected to return and if the full_output switch is activated they return complementary data as well in a tuple.

 

Rather, I think what's most important is having functional equivalents with a more pythonic API, and a cross-reference list in the style of the 'numpy for IDL users' guide but with higher level functionality. I.e. "for readfits instead use pyfits.getdata, for aper.pro use aperturephotom.py (or whatever)."    There's a lot of functionality in the IDL astro library which is not yet available in Python as far as I know, for instance the hextract/hrot/hrebin functions for FITS manipulation with WCS.  I think if we can provide a lookup table from IDL functions into Pythonic semantic equivalents, that will ultimately be much more useful than trying to build a set of syntactic equivalents.  I'm not opposed to translation wrappers for some simple functions, but as soon as it becomes un-obvious how to convert an IDL function call into Python, then you should stop trying and just design a new Pythonic function call (or class) that gets the job done right.

I'm totally with you there.

Rene

 

[Rene Breton]

Hi Tom,

Interesting idea but let me state a few opinions here.

1. For anything to be part of the astropy core package, I think we have to stick to using only Python (and the C/Fortran extensions) and mainstream dependencies like numpy, scipy, matplotlib (and pyfits, pywcs if they are not integrated in astropy).

We really don't want to clutter the main package with things like GDL, pyraf, and such. Otherwise it will quickly become a mess. I personally have no intention of installing any of these. If we are using Python, this is precisely because we wanted to move away from these. Let's let the past generation keep using their old-school stuff and let's move forward as far as astropy's core is concerned. Clearly, the bulk of us putting efforts are interested in python so let's do someone we want and need, and people will adopt it because it's simple, elegant and provide the functionality they need rather than because it's the same old stuff they used to have.

2. I'm not against anyone doing whatever they want like wrappers using GDL or piping stuff to IDL or what not. If anyone sees a point and wants to do it this is great. However, these should be separate packages. They can use and contribute to the astropy core for what's relevant and put the rest in the particular package.

3. Astrobetter's "IDL to Python" is a great initiative and we certainly want to keep expanding it. To me, this is the really useful stuff to anyone who will make the switch.

4. I'm not against a sub-module (astropy.idl) that would simply wrap to the existing numpy/scipy/astropy stuff. Like astropy.idl.readfits(*args, **kwargs). The doc string would be that of what it points to, with may a couple of extra lines at the beginning or the end saying "This IDL's Astrolib functionality has been implemented already in the pyfits package." plus extra info if necessary.

I feel it could rapidly get deprecated though but whatever.

[Marshall Perrin]

On Oct 20, 2011, at 12:44 PM, Rene Breton wrote:

1) Array indexing, given the opposite conventions of IDL and Python for axis ordering. Should idl.max( some_array, dimension=2) return the maximum along the axis that IDL considers axis 2 (which would be the fastest-varying axis for e.g. a 3D cube), or the axis that Python considers axis 2 (the slowest axis, for that example)? This is a trivial example, and at first it seems more straightforward to have the IDL compatibility code use the IDL convention, but this (a) leads to code with lots of axis order swapping that can become convoluted and hard to follow, and (b) makes it harder to use this IDL compatibility layer as a bridge toward a pure Python implementation.

Here to me it's pretty simple. Anything that goes in astropy's core should be pythonic. Array indexing is what it is. The first element of an array is 0, the last dim-1. The axis indexing is pythonic as well. Otherwise, things just become a mess and you end up crashing space probes on Mars because some people still use obsolete imperial units instead of SI ;-)

Imagine you do something with this IDL and pass the "old" dimension = 2, but then you play some more with the array with numpy... This just becomes confusing. In separate packages, people are free to do whatever they want, but I'd certainly recommend they follow Python's.

I agree 100% on all of this. Mixing array index conventions would lead to insane confusion. That's part of why I think that trying to provide direct API compatible IDL code is not a productive route. 

On Oct 20, 2011, at 1:11 PM, Rene Breton wrote:

3. Astrobetter's "IDL to Python" is a great initiative and we certainly want to keep expanding it. To me, this is the really useful stuff to anyone who will make the switch.

And on Oct 19, 2011, at 11:01 PM, Matt wrote:

This is why the AstroBetter idl -> python table is such a great idea. For a lot of routines there is probably a short list of python + numpy + scipy + matplotlib + astropy utilities that does the same thing, and we don't need to write an actual script, just point people to the right stuff, maybe provide examples. It could even be useful for getting people started in Python. Give a dude a fish...

And Vicki Laidler wrote: 

 I've already migrated from IDL to Python, and there are Astron routines that I miss. I would MUCH rather have Python equivalents of those Astron libraries as part of Astropy, than have to install yet another package, and possibly have to dust my IDL skills back off (and upgrade them to GDL skills) in order to troubleshoot problems. 

It seems to me that there is a(n at least partial?) consensus that the most important thing is expanding & enhancing the IDL->Python translation table such that there exists an easily identifiable Pythonic functional equivalent for each item in the IDL library, without trying too closely to match the IDL function call syntax.  Unless there are folks who really strongly feel that an API-compatible version is really compelling, I don't think that's worth much effort. 

I suggest we create a new Wiki page with a list of all the IDL astro library functions (in the same order and subsections as presented on http://idlastro.gsfc.nasa.gov/contents.html ) that recommends the preferred Python equivalent for each of those tasks. The list would be very incomplete at first, but it would expand over time, and in the mean time would give us a nice checklist of what parts of functionality still don't have good Python versions...

 - Marshall

[Thomas Robitaille]

> I suggest we create a new Wiki page with a list of all the IDL astro library
> functions (in the same order and subsections as presented
> on http://idlastro.gsfc.nasa.gov/contents.html ) that recommends the
> preferred Python equivalent for each of those tasks. The list would be very
> incomplete at first, but it would expand over time, and in the mean time
> would give us a nice checklist of what parts of functionality still don't
> have good Python versions...

If we start this on the wiki, we could consider migrating it to the
sphinx docs once it's reasonably stable. But at this stage, should we
maybe mention only numpy/scipy/matplotlib/astropy routines in the
Python column? Certainly I don't think we should list all the
different packages that provide the desired functionality, and I think
that numpy/scipy/matplotlib/astropy should take precedence over any
other package.

Cheers,
Tom

[Matt Davis]

I think we should also go ahead and make an affiliated or core package for holding actual equivalent routines. As often as we can we should defer to just pointing to existing functionality, but that won't work for everything.

- Matt

[Tom Aldcroft]

On Fri, Oct 21, 2011 at 2:08 PM, Marshall Perrin <mpe...@stsci.edu> wrote:
> ...

> It seems to me that there is a(n at least partial?) consensus that the most
> important thing is expanding & enhancing the IDL->Python translation table
> such that there exists an easily identifiable Pythonic functional equivalent
> for each item in the IDL library, without trying too closely to match the
> IDL function call syntax.  Unless there are folks who really strongly feel
> that an API-compatible version is really compelling, I don't think that's
> worth much effort.

Agreed.

API-compatibility is certainly not a requirement, and not even
strictly possible given the language differences. The original idea
was just to create a repository where anyone who wants to port
routines can do so. Prasanth has already ported one useful routine
(lineid_plot) with no previous Python equivalent, and Kelle mentioned
that she has occasionally given undergraduates the task of translating
an IDL astro lib routine. The point is that if an astronomer has the
API, docs, and code already there, it can be easy to just port the
code and then provide it as a resource for the community.

I think there is pretty much 100% agreement that the AstroPy
developers on this list are NOT going to devote energy or resources to
porting the IDL astro lib verbatim, beyond doing the initial setup
(wiki and affiliated package repo) and providing review of
contributions.

And speaking of setup, +1 on Matt's post to set up an affiliated
package to hold IDL astro lib ports.

- Tom

[Thomas Robitaille]

> I think there is pretty much 100% agreement that the AstroPy
> developers on this list are NOT going to devote energy or resources to
> porting the IDL astro lib verbatim, beyond doing the initial setup
> (wiki and affiliated package repo) and providing review of
> contributions.
>
> And speaking of setup, +1 on Matt's post to set up an affiliated
> package to hold IDL astro lib ports.

I agree with this. Regardless of what we do, people are going to want
to port astrolib routines to Python, and so we may as well centralize
the efforts and quality check them. There would be no commitment to
porting everything, but it would just be a place for people to keep
that code and avoid duplication of efforts. The only question
remaining is whether this should live under the astropy organization
or in a separate repository?

Tom

[Matt Davis]

> The only question
> remaining is whether this should live under the astropy organization
> or in a separate repository?

Seems like it would make sense for it to live under the astropy
organization since we're going to encourage the same standards of
coding and documentation, and encourage the use of astropy
functionality. But I'm sure it can work either way if we want to start
up a new pyastron (or whatever) repo.

- Matt

[Erik Tollerud]

I also agree that it makes a lot of sene to make this as an affiliated
package, but definitely *not* include anything in the core that's an
approximately direct port of the IDL interface (except maybe for
really simple stuff like air_to_vac and the like).

I also think it makes sense to put this in the astropy organization,
as it's then easier to convince people to submit to a quasi-official
package, and I think it's ok if that package is more or less a grab
bag of IDL ports.

Does anyone want to volunteer to be the go-to person for this
affiliated package?

I also want to reiterate that this is a great way to convince people
they should start using the more pythonic interface - we give them a
package that does some of the basic stuff that they're used to in IDL,
but then make sure the documentation says "and here's a simpler,
easier-to-use method that uses the astropy core: ..." People will
still sometimes use the IDL-like versions anyway, but that's ok - we
can't win over everyone.

--
Erik Tollerud

[Thomas Robitaille]

Ok, I think we agree that it can live inside the astropy organization.
Many names have been suggested here, but rather than names like pyIDL,
how about something like astrolib-ports or py-astrolib to emphasize
these are direct ports of IDL astrolib routines? (with the installed
module being called astrolibports or pyastrolib).

Tom

[Tom Aldcroft]

I think the name should have a reference to IDL in there somewhere.
For newcomers etc, py-astrolib will sound like a generic collection
of astronomy libraries in python. Also, at least based on the project
URL, the IDL astronomy lib is called idlastro. So maybe pyidlastro?

- Tom

[Thomas Robitaille]

+1 for pyidlastro for the reasons you suggested

Tom

[Wolfgang Kerzendorf]

why not pyastroidl or astropyidl, even better astropydl ;-)

I think pyidlastro is a good name as well.

Wolfgang

[Kyle Barbary]

On 10/21/2011 09:11 PM, Erik Tollerud wrote:
> I also want to reiterate that this is a great way to convince people
> they should start using the more pythonic interface - we give them a
> package that does some of the basic stuff that they're used to in IDL,
> but then make sure the documentation says "and here's a simpler,
> easier-to-use method that uses the astropy core: ..." People will
> still sometimes use the IDL-like versions anyway, but that's ok - we
> can't win over everyone.

Is anyone worried about having two ways to do the same thing? In my
experience a lot of users, once they find a way to do what they want,
will keep doing things that way and not think about it again, even if it
is not the "best" or "correct" method. Personally, I find the philosophy
of having one, and only one, correct way to do something very appealing.

So far, we haven't heard a lot of testimonials of people who want exact
copies of IDL interfaces. Rather, it sounds like most people want the
"lookup table" between IDL routines and the correct way to do the same
thing in python. So, it seems like the only advantage of having the
pyIDL package is that the IDL functionality is available slightly sooner?

- Kyle

[Matt Davis]

For 1 or 2 line solutions the idl -> python table should be
sufficient. For anything much longer than that I think it would get
unwieldy so having the actual routines coded somewhere will be
important. Routines included in pyidlastro (or idlastroports) should
follow best practices, e.g. be the best way to do whatever that
routine does. That may take iterations on submitted routines, but
that's fine.

Every time I tell an astronomer about Astropy they ask whether we're
translating the IDL astronomy library, so this is clearly important.
But I don't want to give people exact duplicates of IDL routines, I
want to give them the Python way of doing what those routines do.

- Matt

[Matt Davis]

I am willing to be a supervisor on this package, but I certainly
welcome anyone else. Especially someone with actual experience with
the IDL astronomy library...

- Matt

[Marshall Perrin]

On Oct 22, 2011, at 5:48 PM, Kyle Barbary wrote:

Is anyone worried about having two ways to do the same thing? In my experience a lot of users, once they find a way to do what they want, will keep doing things that way and not think about it again, even if it is not the "best" or "correct" method. Personally, I find the philosophy of having one, and only one, correct way to do something very appealing.

Yes, I agree. That part of PEP20's wisdom is very appealing to me (and part of why I'm so glad to see all this progress in consolidating our efforts into a coherent whole). I think we should be careful about unleashing "deprecated from the start" code onto the world.  Rather than creating a pyastrolib module specifically, I would  instead suggest we start out thinking about where we might fit ported IDL routines directly into the desired astropy namespace. That we can right from the start point users at code that will be a part of core astropy, rather than putting too much effort into a transitional system. 

On Oct 22, 2011, at 6:04 PM, Matt Davis wrote:

For 1 or 2 line solutions the idl -> python table should be

sufficient. For anything much longer than that I think it would get

unwieldy so having the actual routines coded somewhere will be
important. Routines included in pyidlastro (or idlastroports) should
follow best practices, e.g. be the best way to do whatever that
routine does. That may take iterations on submitted routines, but
that's fine.

I think that just supports my above point -- If the resulting code really is the best way to do something, then why not just incorporate it into the main astropy namespace rather than sticking it somewhere else? If the goal is to produce code that we will be happy to keep using indefinitely into the future as a community, then that code should be in astropy. 

Let's consider the various categories of routines in idlastro, as defined on http://idlastro.gsfc.nasa.gov/contents.html . I assert that for all cases, it's pretty clear where a given routine's equivalent ought to end up in astropy. Here we go: 

Astronomical Utilities: This first section of the idlastro lib is actually the hardest. It contains a mix of routines for time transformations (-> astropy.time), coordinate transformations (->astropy.coords. Would calculation of solar system body positions go here, or else into astropy.ephem?), and miscellaneous astrophysics (cosmology, interstellar extinction, blackbodies, vaccum to air wavelengths, etc.) For those, I propose a new module called "astropy.physics" for procedures that implement nontrivial astrophysical calculations as opposed to the data reduction & analysis code that makes up most of the other sub modules. This section of the idlastro lib also contains some other minor miscellany like plot tick-labeling routines that don't need to be ported given that superior functionality already exists in matplotlib and aplpy. 

DAOPHOT-Type Photometry:    The functionality of these routines should end up within whatever photometry module gets developed in astropy, or else would be methods that can act on Images (e.g. the centroid fitting or sky level measuring routines)

Database Procedures:   These implement a nearly 30-year-old flat text file database format; I see no reason to port any to Python. Instead users should be pointed at more modern database implementations such as sqlite3 or mysqldb. 

Disk I/O (e.g. IRAF files): Gets folded into astropy.io

FITS Header Astrometry: Either pywcs or methods acting on images. 

STSDAS Image manipulation, STSDAS (Binary) table I/O: Again, astropy.io

FITS ASCII & BInary Table I/O, FITS Binary Table Extensions I/O, FITS I/O: Pyfits. Or I guess now that's astropy.io.fits. 

Image Manipulation: These should go into astropy.image

Math and Statistics:   Probably most/all of these already have numpy or scipy equivalents, and there's no need to port any actual code. 

Plotting procedures: Most of these have matplotlib equivalents. lineid_plot is the most interesting exception, and that could live in astropy.spectral perhaps.

Robust Statistics: Many probably already have numpy/scipy equivalents. If not, they could go into astropy.stats

Web Socket Procedures: These routines for querying SIMBAD & Vizier might end up in astropy.io.vo, or else perhaps we could have astropy.io.web

TV DIsplay Procedures: These are just plotting routines, hence have matplotlib equivalents.

MIscellaneous (Non-Astronomy) procedures:   These utility functions pretty much all already have equivalents in the Python standard library.  

So, given that, do we really need a pyidlastro as a catch-all for ported code? I would say not. 

 - Marshall

[Prasanth Nair]

Hello,

On Sun, Oct 23, 2011 at 9:21 AM, Marshall Perrin <mpe...@stsci.edu> wrote:

So, given that, do we really need a pyidlastro as a catch-all for ported code? I would say not. 

 - Marshall

I agree with Marshall.

As Marshall suggested, most of the code outside the Astronomical Utilities section do not need to be ported to Python.

Instead of an "astropy.physics" sub-package, I propose an "astropy.astroutils" sub-package to hold these. There is already an "astropy.utils" sub-package, but that serves a very different purpose.

This also has the advantage that we need not restrict contributions to code ported from IDL.

Prasanth

[Thomas Robitaille]

> Instead of an "astropy.physics" sub-package, I propose an
> "astropy.astroutils" sub-package to hold these. There is already an
> "astropy.utils" sub-package, but that serves a very different purpose.

But this could be very confusing to the user. What exactly are
astroutils compared to, and why would they not be in more specific
sub-modules?

I think the top priority for now is to start the wiki page mentioned
previously on this thread, figure out what can already be done with
numpy/scipy/matplotlib/astropy function by function, and then see if
some utilities are likely to not be in astropy for the near/far future
because they are too specific, and then to create an affiliated
package to contain those.

Tom

[Matt Davis]

We already have a submission for PSF_GAUSSIAN:
https://groups.google.com/group/astropy-dev/browse_thread/thread/5ee6cd662236e382

Is it ready to go into astropy.image? Is astropy.image ready to take
it? I think pyidlastro could be a good place for things until we know
how to fit them in. Maybe we'll just see how things fall out on a case-
by-case basis.

Any way we do this it is important that we do it because the IDL
astronomy library is a huge reason people stick with IDL, and it's the
first thing people want when I encourage them to use Python.

- Matt

[Thomas Robitaille]

On 23 October 2011 10:39, Matt Davis <jiff...@gmail.com> wrote:
> We already have a submission for PSF_GAUSSIAN:
> https://groups.google.com/group/astropy-dev/browse_thread/thread/5ee6cd662236e382
>
> Is it ready to go into astropy.image? Is astropy.image ready to take
> it? I think pyidlastro could be a good place for things until we know
> how to fit them in. Maybe we'll just see how things fall out on a case-
> by-case basis.

No - astropy.image is still being discussed, and from what has been
said so far, I think that photometry tools (to which this is related)
are first going to be developed in an affiliated package.

> Any way we do this it is important that we do it because the IDL
> astronomy library is a huge reason people stick with IDL, and it's the
> first thing people want when I encourage them to use Python.

As I said before, I think what we should start with is a
correspondance guide for IDL astrolib to
Python/numpy/scipy/matplotlib/astropy. Basically for each routine in
here:

http://idlastro.gsfc.nasa.gov/contents.html

we can have a few lines of code to show how to do it in Python (if it
is already possible). I've created a wiki page at:

https://github.com/astropy/astropy/wiki/Python-guide-for-IDL-astrolib-switchers

which contains all the astrolib routines, and anyone can go and add
examples of how to do the tasks in Python. See the example for AVG(),
which is a typical example where we should just tell people how to do
it in Python rather than replicate the AVG() API!

I think for now we need to restrict ourselves to
Python/numpy/scipy/matplotlib/astropy. Once the wiki page converges to
something fairly complete, we could always move it to the main astropy
docs.

We can see how this works, and if the wiki page becomes more confusing
than useful, we could reconsider.

Cheers,
Tom

[Marshall Perrin]

I've created a small github site which contains a handful of IDL astro lib routines which I ported to Python at various points in the past few years: https://github.com/mperrin/misc_astro
I still think our focus should be making good python interfaces, so I explicitly do not advocate incorporation of any of these into astropy as is. But I wanted to get the code online in any case so the community can see that these few functions have already been ported.

List of functions: ccm_unred gcirc posang sunpos tvbox tvcircle

There's also an idlbase.py that contains many of IDL's intrinsic functions like the *indgen and some str* functions, rebin, congrid, and bytscl.

- Marshall

[Erik Tollerud]

Do you think you could move those to the pyidlastro package
(https://github.com/astropy/pyidlastro) as soon as its up-and-running?
Certainly a good place to start...

--
Erik Tollerud

[Tom Aldcroft]

As Eric T mentioned, an affiliated package has been created at
https://github.com/astropy/pyidlastro to serve as a home for ports of
existing IDL functionality without immediate Python counterparts.
This was decided by the coordinating committee as the outcome of a lot
of productive discussion. I have volunteered to be the "keeper" of
this package, but definitely hope that others who have really done
prior work in this area will take an active or leading role. This is
a strange package in that the astropy project goal is to make it
deprecated as soon as possible, but being pragmatic it may serve a
useful interim role.

I've added a "pyidlastro" section to the developers list
https://github.com/astropy/astropy/wiki/Developers so anyone is
welcome to sign up. Next tasks are:

- Start filling out the pyidlastro wiki page:
https://github.com/astropy/pyidlastro/wiki/Python-guide-for-IDL-astrolib-switchers
to include information that will help contributors (e.g. pointers to
style guide, template modules, documentation info).
- Continuing filling out the pyidlastro wiki with astropy/numpy/scipy
functional equivalents
- Establish the initial package structure in pyidlastro
- Start importing existing codes
- When there is something concrete there and perhaps in conjunction
with the Astropy "pre-release" we should put out a wider call for
contributions.

Important ground rules:

Make it as clear as possible that these IDL-style ports should,
whenever possible, clearly point to whatever other astropy thing does
the same thing (if it exists). We definitely don't want to be sucking
much developer energy into porting IDL routines to python with
IDL-like interfaces.

As with all affiliated packages, it should follow the same coding
rules as astropy, even documentation and testing. For documentation,
as long as the docstring is fine, we can just do an automodule though
to generate the sphinx docs. For testing we'll need to strike a
balance given the unique nature of this package.

Any routine that has a corresponding function, even with a different
API, should just be in the wiki page. If it's a whole function that
doesn't have an equivalent in pure
python/numpy/scipy/matplotlib/astropy then it can be in pyidlastro. If
a routine is subsequently implemented into astropy, the pyidlastro
one should be deprecated and the new one added to the wiki.

Cheers,
Tom A