[AstroPy] Practical Python for Astronomers web tutorial

[Victoria G. Laidler]

Hi Tom,

Tom Aldcroft wrote:
>> 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.
> We are basically in agreement and I totally discourage use of "from
> whatever import *" at the Python prompt. The people who go through the
> workshops will not even know such a construct exists!  (OK, it is
> mentioned exactly once in a parenthetical side note).  But clobbering
> imported functions or even built-in functions is always possible with
> Python, and that is considered a feature by many.
>   
Clobbering imported or built-in functions with local functions is 
definitely a feature.
Accidentally clobbering a function with a _variable_ of the same name is 
the case I'm talking about.
Oops, I can't call the std() function anymore because I read a column 
out of a table and
assigned it to a variable named std -- that sort of thing.

>> 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.
>>     
>
> This is a workable option but as a style issue it's not my preference.
>  I also note that "import pylab as P" violates a number of PEP8
> recommendations and I do take PEP8 pretty seriously, although
> practicality beats purity.  :-)
>   
Ah, right. I'm slowly trying to wean myself to a more compliant "import 
pylab as pl" or something similar, but "pl" reads as "power law" to my 
IRAF.synphot-saturated brain. ;)

>> (...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.)
>>     
>
> That would require from pylab import *, or reworking them all to use
> package prefixes everywhere.  I understand your position but at least
> for now will leave the examples as they are.
>   
Understood.
> **However**, based on feedback from this list we will definitely add
> substantial new content with a discussion of namespaces, what's going
> on with pylab and import *, and how to translate the interactive code
> snippets into standalone python programs.
>   
Great!
>> 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.
>>     
>
> I'm sure some will disagree, but I would argue it is reasonable to
> "Preach (or teach) what you practice", and that is exactly the
> perspective of Practical Python for Astronomers.  Pylab or derived
> IPython variants are ubiquitous in interactive data analysis software
> for astronomy, and for good reason. It makes life easy for users.
> Witness CIAO, CASA, PyRaf, HIPE - they feature environments with a
> rich set of preloaded functions, magic imports, or else the dreaded
> "from package import *" within examples.  For interactive analysis
> this is what astronomers demand and it's what developers provide.
That's a fair point.

cheers,
Vicki