[AstroPy] Practical Python for Astronomers web tutorial

Tom Aldcroft aldcroft at head.cfa.harvard.edu
Wed May 25 10:52:22 EDT 2011


I strongly endorse teaching good practices at the undergraduate and
early graduate level, and I wish that a year or more of programming
courses were a universal requirement for a PhD in astronomy.  Sadly
this is not the case and as you note many astronomers have terrible
coding practices.

Even more sad is my experience (repeated over and over) that by the
time people get to be postdocs and beyond they are mostly set in their
ways.  Those who appreciate programming as an art will naturally adopt
good practices, but the majority just do whatever it takes to quickly
get a result and are simply not interested in coding practices.  You
can preach all you want but it won't help.  I have one colleague who
has successfully been doing data analysis using AWK for 20 years, so
just getting him to look at Python has been a challenge.

- Tom

On Wed, May 25, 2011 at 2:01 AM, Taro Sato <ubutsu at gmail.com> wrote:
> Hi there.  I also hope whoever will be writing tutorials and teaching
> materials actually try to preach good practices.  Namespace is there
> for a reason as are other conventions and coding standards.  I
> recently had to customize codes written by astronomers and it was an
> absolute nightmare dealing with all the global variables defined in
> different include files....  Yes the code worked but why don't you
> make them break the rules only after they know what they are doing?
>
> Taro
>
>
> On Wed, May 25, 2011 at 2:35 AM, Vicki Laidler <laidler at stsci.edu> wrote:
>> Hi Tom,
>>
>> I'm going to second Joe's emphatic prohibition on "from whatever import *", for two reasons:
>> not only as a matter of purity, but also as a practical matter. Using pylab specifically, I have
>> more than once clobbered a few of my own variables when I did "from pylab import *" after
>> doing a bunch of data analysis. Or, conversely, I accidentally clobber a pylab function with
>> one of my own variables.
>>
>> I recommend the idiom "import pylab as P". I use this with our local
>> scientists all the time, explaining to them that this sets P as an abbreviation for pylab.
>> Then we use P.plot and so on. Prepending a "P." in front of the pylab commands is really
>> very low typing overhead and visual clutter, and I haven't heard or seen any resistance to it.
>> We import numpy in a similar way.
>>
>> (...and while we're on the subject of visual clutter, I may be the only person in the world who
>> utterly loathes iPython, but I'd like to second the request to make sure your demos work
>> in plain vanilla python as well.)
>>
>> I do agree that pylab is very valuable for this kind of tutorial and for astronomers' Python use
>> in general. In real life I do "from pylab import *" for quick&dirty interactive work, but I would
>> never teach with it and I don't do it in a session where I'm doing any non-trivial amount of
>> data manipulation because I've been burned.
>>
>> cheers,
>> Vicki Laidler
>>
>>
>> ________________________________________
>> From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Tom Aldcroft [aldcroft at head.cfa.harvard.edu]
>> Sent: Wednesday, May 25, 2011 12:55 AM
>> To: jh at physics.ucf.edu
>> Cc: astropy at scipy.org
>> Subject: Re: [AstroPy] Practical Python for Astronomers web tutorial
>>
>> Hi Joe,
>>
>> Thanks for the detailed review and comments on the tutorial site, this
>> is very helpful!  In general I agree with your points and we'll plan
>> to tweak the content accordingly.
>>
>>> 1. Don't use:
>>>
>>> from whatever import *
>>>
>>> or any shortcuts like 'ipython -pylab' that do that.  It's poor style
>>> and against the practice of the numpy community in all its docs and
>>> demos.  Remember that the numpy, scipy, and matplotlib developers can
>>> in the future put anything they want in their namespaces, and a new
>>> release could break your working code because of a namespace conflict
>>> that doesn't exist when you write it.  While that may not bite you for
>>> your workshops, it will eventually bite anyone who writes enough code
>>> like that.  Those problems can be hard to find.
>>
>> Now I'm going risk being branded as a heretic or lazy or a bad
>> influence, or all of the above...
>>
>> The decision to use "pylab" was a deliberate one based on the desire
>> to present Python as a simple and easy tool for the research
>> astronomers that participated in the workshops.  For a first look at
>> Python for analysis there is a real advantage to reducing the visual
>> and conceptual noise in the form of package prefix names everywhere.
>> For astronomers who have been using IDL or Matlab for 20 years this
>> would make Python seem far less attractive.  In our workshops the
>> majority of people were already fluent in some analysis environment
>> but few had much experience with Python.
>>
>> On the topic of rigorously avoiding the implicit "import *", the
>> workshops tend to follow the Zen of "practicality beats purity".  Most
>> astronomers I know write only simple programs and are highly focused
>> on getting an answer quickly so they can have results for their talk
>> next week.  In that regime I think a "pylab" approach is not only
>> acceptable but the most efficient.  Of course there is no question
>> that for a package module or longer program that will get re-used
>> later, one needs to worry about namespaces and following best
>> practices.  And this would be a perfect topic for a new workshop
>> chapter "Beyond one-off scripts: writing real programs in Python"
>> Volunteers? :-).  You're right that interactive analysis is not the
>> whole story.
>>
>> I should note that I never use "import *" in any scripts and do not
>> endorse ever using that construct explicitly in a script.  For
>> interactive plotting and analysis I use "ipython -pylab" and typing
>> plus execfile(), otherwise always explicit import statements.
>>
>>> Also, the title of each workshop has the first word on the end of a
>>> breadcrumb trail and the rest on a second line.  Maybe put in a line
>>> break before the title.
>>
>> I don't understand what this means.  Is the HTML rendering differently
>> for you or ??
>>
>> Thanks, Tom
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>
>
>
> --
> Taro Sato
> Department of Astronomy & Physics
> Saint Mary's University             email: taro at ap.smu.ca
> Halifax, NS B3H 3C3                 phone: (902)420-5027
> Canada                                web: http://ap.smu.ca/~taro
>
>



More information about the AstroPy mailing list