This is the part 2 of a step-by-step training on scientific programming with python. The target audience is first-years in engineering schools. There is no pre-requisite skill.
This training is usually done in groups with a trainer. However you can probably use most of this material for self teaching.
Programs, Notebooks, what about Excel spreadsheets?
Excel ( or any more ethical alternative) do allow you to compute and explore data, sometime with quite powerful tools.
However, like you need excel when you feel your pen & paper is too limited , there are times when you want to go on a larger scale than that. What if you want to use this computation inside an other tool? Repeat it thousands of times for uncertainty quantifications? Run it on memory challenging datasets? You can do it with Excel, but it was not designed for this use.
Programming is simply the next level after Excel. With the growth of data flows, and the competition of advanced data processing techniques, spreadsheets are losing some grounds. Some are even touting “Python already replaced excel in banking”. Even journalists rely more on more on datavisualization for the storytelling, a sport out of the reach of spreadsheets.
Whatever, maybe you are still not convinced by the need of programming and spreadsheets. All the same, You should better know your enemy… Follow this way.
A Jupyter notebook
This second session will be done using a Jupyter notebook. Jupyter is the contraction of Julia, Python and R, three trendy languages today in data analytics. The future is always uncertain, but right now data-science is exploding, Python is rising, and self-taught programmers on the rise.
The Jupyter Notebook Format is particularly suited to the common task of data processing. Let me stress it again, especially if your future job involves only a little bit of programming, there are strong chances that this little bit is in Python or R, and run under a notebook.
Starting up a Jupyter notebook
In three steps , assuming you still have you v.env. (e.g. totoro) from part one, activate it:
>source $HOME/Python_Venvs/tototo/bin/activate
(totoro) >
Then install Jupyter yin your python environment:
pip install jupyter
Finally launch Jupyter notebook
>jupyter notebook
There are countless extensive tutorials on the topic. As usual, the official Jupyter beginner’s guide is a good source.
Getting a notebook from someone and using it
A Jupyter notebook is a document with the extension .ipynb.
At COOP, most of our training notebooks are on our COOP notebooks gitlab repository. You can even read on gitlab the content!
Here are the three steps to open one via the command line:
- Go on this link, search your notebook, download the file and put it where you want (e.g.
~/MY/AWESOME/LOCATION/rocinante.ipynb). - Set yourself in this repository, (
(totoro) > cd MY/AWESOME/LOCATION) - Open it with a v.env. featuring Jupyter
(totoro) >jupyter notebook rocinante.ipynb.
If the notebook need some specific packages, simply install the missing ones in your v.env. like you always do.
The notebook on python basics
We will start with the following notebook : python getting started. This notebook cover most of the basics.
Exercise your eyes
With this notebook, learn to recognize what you read. This is only a sightseeing tour. You do not need to understand all the inner working for now. However, you should be able a the end to spot and name:
- a variable
- a function definition
- a function call
if,for, andwhileblocks.- a class definition (it is an object !)
- a class call (an object creation)
- a list
- a dictionary
- an iterable (huh?)
You will also learn the notebook ways:
- restart the notebook
- restart from a previous point
- add or remove a cell
- complete a documentation cell
A bit of philosophy
When you will search for solutions on programming forums like stack overflow, people often refer to one of the “Zen of python” rules. This is why you should read them at least once, or you will always miss their point.
The way of writing python is definitely strongly influenced by several “sayings”. Let us have a look.
>>> import this
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!