[AstroPy] Coding Guidelines draft (comments encouraged)

Erik Tollerud erik.tollerud at gmail.com
Mon Jul 25 08:09:37 EDT 2011


I have made a new version of the coding guidelines and posted them to:
 http://astropy.org/development/codeguide.html

This version incorporates most of the feedback we've gotten so far on
this thread, so if you've suggested something, you might want to look
to make sure what's in there is what you had in mind.  In particular,
Michael, you may want to look at the new phrasing for the data file
limit.  Additionally, a few of you may want to look over the new
phrasing for when C extensions are acceptable.


One thing I have *not* yet altered is the section on super() and
multiple inheritance, as the discussion does not seem to have
concluded.



Finally, a few specific items:

> Maybe it's too early for this, but I think some version numbers should
> be added regarding numpy, scipy and matplotlib compatibility, at least
> to assure some consistency between the various core components.

This definitely needs to be addressed, but I think the better way to
address this is to include a specific version in the astropy setup.py
script, and just say that the "supported version is that specified as
required by setup.py".  That makes it easier to keep things up to
date, but of course we wouldn't bump those version numbers without
good reason.  I've included this in the new draft, but if anyone
disagrees with this approach, I can change it.


> What about weave?  I've fallen in love with using inline C codes for
> the obvious performance advantage when the stock NumPy/SciPy routines
> don't cut it...  just for quick and tiny hacks and such.  It's much
> less cumbersome than writing full blown C extensions for small tasks.

My experience with weave is that it is great for doing quick small
hacks and the like, but it can be very tricky to get it to deploy well
- in many cases weird compiler version-specific glitches come up if
you're not careful.  I've also heard that weave is having trouble
finding someone to be its lead developer, as the original author is no
longer (although that may have changed).  Additionally, I think
there's no way to package the final product if the code includes weave
- weave by nature requires a compiler matched to scipy, as far as I
understand it (although I could be wrong about that).

So given that you can do the same things with Cython, I'm inclined to
say weave is too much of a distribution challenge to be allowed,
despite the very nice features it offers.  Any other opinions on the
matter?


-- 
Erik Tollerud



More information about the AstroPy mailing list