1. Python  Monty or Snake?

2. Monty?  Spam, spam, spam and eggs  Dead parrots  Eric Idle, John Cleese, Michael Palin, etc.

4. Why Python  Sysadmin acceptance  Right structures and system access  Obj-orient, and OS access  Interpret or compile?  Popularity trend 

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

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

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

8. Lets Python  Open a terminal  Start ipython  In [1]:  Spam=6+2  print spam

9. Example  Import more.py in ipython  syntax (indentation)  loops, variables, data types, modules (library)

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

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

12. Libraries of modules  Access Libraries of modules. EG. the sys library  import sys  dir(sys)  sys.__doc__  Use the following example

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

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

15. Comments  Demo only intended as a discussion of features, not programming style  Many more library modules  See library link for morelibrary link  Try some of these.  Use dir(module) and  module.__DOC__ with your new more()

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

17. Now do the tutorial  Tutorial http://docs.python.org/tutorial/http://docs.python.org/tutorial/  Ch 3-7  Also see the if __name__ == ‘__main__’ trick herehere

18. Assignments  HW: Work through the tutorial

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