Python

greenbeansneedlesSoftware and s/w Development

Dec 13, 2013 (3 years and 10 months ago)

72 views

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!