• Has significant/syntactic whitespace
In [ ]:
if something:
    do something

is not the same as

In [ ]:
if something:
do something

ProTip(TM): Always use 4 spaces for all indentation! It adds at least one to the $\log_{10}(ease_{\rm life})$

  • Is Object-Oriented at all levels... But hides it well when you want it to! - more on that next session
  • Is an interpreted language (like IDL, Java, unlike C, FORTRAN) - more on that too next session

Why do you care that it's interpreted?

Because instead of doing

% mycode

you effectively always do

% python mycode.py

Which means you have to know which python you're running

Which causes no end of trouble:

% pip install astropy
% python
Python 3.4.3 (default, Aug 26 2015, 18:29:14) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import astropy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'astropy'

(The python that % pip references is a different python from the one that % python finds)

Our recommended solution: Anaconda (more on that in a bit)

What is all this funky business?

import astropy 
import astropy.coordinates
from astropy.coordintes import angles
from astropy.coordintes import SkyCoord

Package Terminology

  • “package”: the biggest thing. E.g., astropy, numpy, sunpy. A directory with an __init__.py
  • “module”: a single something.py file - the module is “something”
  • “subpackage”: a package within a package
  • “source directory/folder”: the directory/folder with all of a codes “stuff”
  • “repository”/“repo”: the source directory in version control
  • “submodule”: a git repo embedded in another git repo

Package Example

README
LICENSE
setup.py

my_package/__init__.py
my_package/my_module.py
my_package/second_module.py
my_package/subpackage/__init__.py
my_package/subpackage/another_module.py
In [ ]:
import my_package
from my_package import my_module
from my_package import second_module
from my_package import subpackage
from my_package.sub_package import another_module

Now back to the imports

import astropy 
import astropy.coordinates
from astropy.coordintes import angles
from astropy.coordintes import SkyCoord

import astropy
import astropy.coordinates
from astropy.coordintes import angles
from astropy.coordintes import SkyCoord

astropy is a:

package

Which you would use from python as

astropy.<something>

import astropy
import astropy.coordinates
from astropy.coordintes import angles
from astropy.coordintes import SkyCoord

coordinates is a:

subpackage

Which you would use from python as

astropy.coordinates.<something>

import astropy
import astropy.coordinates
from astropy.coordintes import angles
from astropy.coordintes import SkyCoord

angles is a:

module

Which you would use from python as

angles.<something>

import astropy
import astropy.coordinates
from astropy.coordintes import angles
from astropy.coordintes import SkyCoord

SkyCoord is a:

variable (more specifically, a class)

(This was a bit of a trick question: imports like this can import things from inside modules just as easily as modules themselves. You don't necessarily know that what you're getting is a module without knowing what's actually in the package.)

Which you would use from python as

coord = SkyCoord(3, 4, unit='degrees')

One more special but common case to consider:

from astropy import units as u

u is a:

module

Actually, you use u here just the same as how you'd use units if you'd done from astropy import units. The as part is just a way to set a local "alias" for quick-and-easy use.

And in fact these two yield the exact same as from astropy import units as u:

import astropy.units as u
from astropy import units
u = units

Why is it useful?

Why is it useful?

  • It lets you install into your home directory
  • It lets you install new packages easily: 
    % conda install astropy
    Even if they are community tools ("halootls" is a cosmological simulation analysis package): 
    % conda install -c astropy halotools
  • It also lets you manage lots of different python "environments": 
    % conda create -n my_experimental_environment python=2.7 astropy=1.0
% source actvate my_experimental_environment
% cd /that/thing/my/python/collabortor/sent/me
% python setup.py install 
...
    Which means you can delete broken stuff without destroying your machine! 
    % conda env remove -n my_experimental_environment
% conda create -n my_better_environement  anaconda python=3.5 astropy=1.2
% source actvate my_better_environement
% python setup.py install 
...

Now let's all get it working

Go to https://www.continuum.io/downloads (or just google "Anaconda download")

Download and install 3.5 (or 2.7 if you really know you want it)

Open a terminal and try conda list, and which python. The latter should show something like: 

/Users/<yourname>/anaconda3/bin/python

and not

/usr/bin/python

nor

/sw/bin/python

If you want IRAF in python, you can also check out http://astroconda.readthedocs.io/en/latest/

(Note that this, and a lot of other useful conda bits requires the bash shell. Type echo $SHELL to see what you have, and if it's not bash, try going into bash before using Anaconda)

If you're done and bored, help populate https://github.com/spacetelescope/pylunch/wiki !