[AstroPy] Practical Python for Astronomers web tutorial

[Tom Aldcroft]

> 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.

> 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.  :-)

> (...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.

**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.

> 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.

> 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
>
>