Guided self-study course, Session 1
Fall 2014
You're our first cohort for this method. So expect some hiccups, and please provide feedback.
Instruction time is focused on what the students need that week: lecture, demos, discussion, etc.
Students should:
Try to have at least one or two questions for class.
Champaign Urbana's Python User Group
http://www.py-cu.org
Student chapter of ASIS&T at GSLIS.
Association for Information Science and Technology
Just starting up!
Elizabeth Wickes
@elliewix
wickes1@illinois.edu
www.elizabethwickes.com
Co-organizer of Py-CU
From sociology/psychology
{quant,qual}//<3
Current GSLIS student in
curation and SODA
Unless you want to be
Web languages
HTML, JavaScript, PHP..
Software languages
Java, C++, Visual Basic...
Language style
Abstraction level
Methodological approach
and so many more...
>>> import this
The Zen of Python, by Tim Peters
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!
...
[1] http://cacm.acm.org/blogs/blog-cacm/176450-python-is-now-the-most-popular-introductory-teaching-language-at-top-us-universities/fulltext
Let's just get out a chart...
Strongly
typed
Weakly
typed
Dynamic
Static/
Declared
>>> import this
The Zen of Python, by Tim Peters
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!
>>> if 5 == 5:
... print "new hotness"
... print "because math"
if (5 == 5) {
System.out.println("old and busted");
System.out.println("because math");
}
(I kid, I kid...)
␠␠␠␠
␠␠␠␠
>>> import this
The Zen of Python, by Tim Peters
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!
>>> if 5 == 5:
... if 6 == 6:
... print "fhew"
... print "whoa nesting"
>>> if 5 == 5 and 6 == 6:
... print "math reality still works"
... print "with less nesting"
␠␠␠␠
␠␠␠␠
␠␠␠␠
␠␠␠␠
␠␠␠␠
␠␠␠␠
␠␠␠␠
We'll keep building up this concept.
Let it be hazy for now.
Try some examples as we go.
int
float
str
""",",'
list
We'll talk about these a lot more later on.
True
We'll talk about these a lot more later on.
Let's say I want to give the int value of 1,203,109 a name. How about my_big_number?
This also works with text.
>>> my_big_number = 1203109
>>> my_big_number
1203109
>>> my_big_number * 2
2406218
>>> my_big_number /3
401036
>>> my_big_number % 3
1
>>> my_big_number / 3.0
401036.3333333333
>>> my_other_number = my_big_number * 4
>>> my_other_number
4812436
>>> first = "Elizabeth"
>>> family = "Wickes"
>>> full = first + " " + family
>>> full
'Elizabeth Wickes'
Remember that dynamic thing?
>>> stuff = 1
>>> stuff
1
>>> type(stuff)
<type 'int'>
>>> stuff = "I'm now a string"
>>> type(stuff)
<type 'str'>
Spoiler alert: you'll be fine
* Multiply: 2 * 3 = 6
+ Addition: 2 + 2 = 4
- Subtraction: 2 - 2 = 0
** Exponent: 4 ** 2 = 16
% Modulo (find remainder):
4 % 2 = 0
12 % 6 = 0
3 % 2 = 1
== Equality check (logical operator): 5 == 5 = True
Division gets weird
1 / 2 = 0 but 1.0 / 2.0 = 0.5
You get what you give.
Don't worry so much about this yet. You'll get it in practice.
Some operators work with non-numbers.
Plus (+) will work between two strings.
Multiply (*) will work between a string and an integer.
>>> 2+2
4
>>> "two" + "two"
'twotwo'
>>> "two" * 2
'twotwo'
But some don't work...
>>> "2" + 2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects
>>> "two" * 2.3
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: can't multiply sequence by non-int of type 'float'
Python for Informatics