Transcript Python
Python
Monty or Snake?
Monty?
Spam, spam, spam and eggs
Dead parrots
Eric Idle, John Cleese, Michael Palin, etc.
Why Python
Sysadmin acceptance
Right structures and system access
Obj-orient, and OS access
Interpret or compile?
Popularity trend
Outcomes
Explain Python rationale
import this # for the Zen of python
Code in Python – for sysadmin
Command line (Python vs. Ipython
Python IDE (Eclipse/pydev – discuss)
Access Python Resources
Style
Perl:
There is more than one way to do it
(TIMTOWTDI)
Python:
There should be one– and preferably only one –obvious
way to do it – Zen of Python
Although that way may not be obvious at first unless
you’re Dutch
“clever” is NOT a compliment in Python
Prepare to code!
Python is built into Linux and OS X. Easy to install in Win
Python at command line
SDK: install Eclipse and Pydev
If you want Ipython in Ubuntu …
Look for Synaptic Package Manager (admin)
Search & install ipython
Lets Python
Open a terminal
Start ipython
In [1]:
Spam=6+2 ⏎
print spam ⏎
Example
Import more.py in ipython
syntax (indentation)
loops, variables, data types, modules
(library)
Python Characteristics
Multi-paradigm: structure- supported but not enforced
Object Oriented (objects, methods etc.)
Structured programming (a’ la Pascal)
functional programming etc. (evaluate fns, avoid
states)
dynamic (but strong) typing and name resolution
syntax (indentation)
command line development
Python vs. IPython
Why IPython
Many reasons, see ch 2 is Linux Admin text
PLULSA by Gift and Jones
OS commands like ls and pwd and cd work in IPython but
not in regular Python command-line
Libraries of modules
Access Libraries of modules. EG. the sys library
import sys
dir(sys)
sys.__doc__
Use the following example
Use a combination of IPython
and Eclipse
Try out ideas in Ipython
If it doesn’t work on command line it won’t work work in a
.py script file.
Then create the code in Eclipse
‘more’ demo
# A simple version of a 'more' function. R. Helps 2010, edited from a "Programming
Python" example
# Call this function with more(text_string)
# Not an example of excellent code style. Done to show several aspects of Python
def more(text, numlines=15):
lines = text.split('\n')
# split the text string into separate strings at the newline
# .split method (function) defined for text objects.
print lines
# just for debug. See that the text string has been split
count = 0
while lines:
# loop through all the text strings
# Notice the ':' and the (lack of) parentheses and the (strict) indentation
chunk = lines[:numlines] # the :number 'slices' off a chunk
# slice notation for text strings textstring[a:b]
# omitting 'a' defaults to 0 (beginning of string)
# omitting 'b' defaults to end-of-string
lines = lines[numlines:]
for line in chunk:
count+=1
# count the lines we print
print count,': ', line
if lines and raw_input('More? ') not in ['y', 'Y']:
# raw_input reads as text
break
print '===== End text======= Count=', count
Comments
Demo only intended as a discussion of features, not
programming style
Many more library modules
See library link for more
Try some of these .
Use dir(module) and
module.__DOC__ with your new more()
Scripting Philosophy
Create a small working core and then add features
Bad practice for large programs
Try out each idea on the command line first
If you can’t make ‘adduser’ work on the command line, it
will never work in Python
Now do the tutorial
Tutorial http://docs.python.org/tutorial/
Ch 3-7
Also see the if __name__ == ‘__main__’ trick here
Assignments
HW: Work through the tutorial
The Zen of Python
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!