ten small Python programs

S

Steve Howell

I've always thought that the best way to introduce new
programmers to Python is to show them small code
examples.

When you go to the tutorial, though, you have to wade
through quite a bit of English before seeing any
Python examples.

Below is my attempt at generating ten fairly simple,
representative Python programs that expose new users
to most basic concepts, as well as the overall syntax.

It was an interesting exercise. I constrained myself
to ten lines or less, and it was pretty easy to
incorporate loops, conditionals, print, open(), lists,
tuples, dictionaries, and imported modules.

It was harder to show classes, and my ShoppingCart
class is nothing more than an encapsulation of a list,
which has dubious value (although it's the start of
something more useful).

Anyway, here goes:

------
print 'hello world'

------
for name in ('peter', 'paul', 'mary'):
print name

------
# This is a Python comment. \n is a newline
name = raw_input('What is your name?\n')
print 'Hi', name

------
parentRabbits, babyRabbits = (1, 1)
while babyRabbits < 100:
print 'This generation has %d rabbits' %
babyRabbits
parentRabbits, babyRabbits = (babyRabbits,
parentRabbits + babyRabbits)


------
# def defines a method in Python
def tax(itemCharge, taxRate = 0.05):
return itemCharge * taxRate
print '%.2f' % tax(11.35)
print '%.2f' % tax(40.00, 0.08)


------
import re
for test_string in [ '555-1212', 'ILL-EGAL']:
if re.match('\d\d\d-\d\d\d\d$', test_string):
print test_string, 'is a valid US local
phone number'
else:
print test_string, 'rejected'

------
prices = {'apple': 0.40, 'banana': 0.50}
myPurchase = {
'apple': 1,
'banana': 6}
groceryBill = sum([prices[fruit] *
myPurchase[fruit]
for fruit in myPurchase])
print 'I owe the grocer $%.2f' % groceryBill


------
class ShoppingCart:
def __init__(self): self.items = []
def buy(self, item): self.items.append(item)
def boughtItems(self): return self.items
myCart = ShoppingCart()
myCart.buy('apple')
myCart.buy('banana')
print myCart.boughtItems()


------
# indent your Python code to put into an email
import glob
pythonFiles = glob.glob('*.py')
pythonFiles.sort()
for fn in pythonFiles:
print ' ------'
for line in open(fn):
print ' ' + line.rstrip()
print

------
import time
now = time.localtime()
hour = now.tm_hour
if hour < 8: print 'sleeping'
elif hour < 9: print 'commuting'
elif hour < 17: print 'working'
elif hour < 18: print 'commuting'
elif hour < 20: print 'eating'
elif hour < 22: print 'resting'
else: print 'sleeping'





____________________________________________________________________________________
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
 
S

Steven Bethard

Steve said:
I've always thought that the best way to introduce new
programmers to Python is to show them small code
examples.

When you go to the tutorial, though, you have to wade
through quite a bit of English before seeing any
Python examples.

Below is my attempt at generating ten fairly simple,
representative Python programs that expose new users
to most basic concepts, as well as the overall syntax.


Very cool! Do you mind putting this up on the Wiki somewhere so that we
can link to it more easily? Maybe something like:

http://wiki.python.org/moin/SimplePrograms

<nitpick>
Though the code should probably follow PEP 8 guidelines, e.g.
under_scores instead of camelCase for object and method names:

http://www.python.org/dev/peps/pep-0008/
class ShoppingCart:
def __init__(self): self.items = []
def buy(self, item): self.items.append(item)
def boughtItems(self): return self.items
myCart = ShoppingCart()
myCart.buy('apple')
myCart.buy('banana')
print myCart.boughtItems()

I think boughtItems() is probably not a good example of Python code
since in this case, you should probably just write ``my_cart.items``.
Maybe it should define ``__len__`` instead? Or maybe something like::

def select_items(self, prefix):
return [item for item in self.items if item.startswith(prefix)]


STeVe
 
P

Paul McGuire

I ***love*** this "10 Little Programs" idea! As soon as I get a
breathing space, I'm going to add a "10 Little Parsers" page to the
pyparsing wiki!

<nitpick>
Though the code should probably follow PEP 8 guidelines, e.g.
under_scores instead of camelCase for object and method names:

http://www.python.org/dev/peps/pep-0008/
</nitpick>

Really? Underscore-separated words preferred over camel case? What
is the rationale for this? This style is so retro/80's/C-ish. It
seems more like a Java backlash to me than anything else. If we (or
Guido) don't like changing case to indicate word breaks, why are class
names to be UpperCamelCase, and not Capitalized_with_underscores? If
there is a casing convention nit to pick, I'd focus on UpperCamelCase
for class names, lower case (either with underscores or mixed case)
for attributes and method names, and UNDERSCORE_SEPARATED_ALL_CAPS for
constants.

If we want to just say "well, PEP-8 says such and such," I think this
is an area where the thinking has possibly evolved since 2001. Also,
I think the PEP would benefit from explicitly discouraging some
practices, such as Hungarian notation.
class ShoppingCart:
def __init__(self): self.items = []
def buy(self, item): self.items.append(item)
def boughtItems(self): return self.items
myCart = ShoppingCart()
myCart.buy('apple')
myCart.buy('banana')
print myCart.boughtItems()

If you want to nitpick, I'd rather go after the one-liner methods with
the body on the same line as the def statement.

How's this for a better non-trivial method example:

MAX_ITEMS_FOR_EXPRESS_LANE = 10
def canUseExpressLane(self):
return (len(self.items) <= MAX_ITEMS_FOR_EXPRESS_LANE)

or call it "can_use_express_lane" if you must.

I guess pyparsing with its mixedCase functions and attributes is
doomed for the Dunce Corner. Too bad for BeautifulSoup, cElementTree,
and wxPython that are also at variance with this canon of Python
coding style. ("Modules should have short, all-lowercase names. ...
Python packages should also have short, all-lowercase names, although
the use of underscores is discouraged.")

-- Paul
 
S

Steve Holden

Paul McGuire wrote:
[...].
I guess pyparsing with its mixedCase functions and attributes is
doomed for the Dunce Corner. Too bad for BeautifulSoup, cElementTree,
and wxPython that are also at variance with this canon of Python
coding style. ("Modules should have short, all-lowercase names. ...
Python packages should also have short, all-lowercase names, although
the use of underscores is discouraged.")
Although the names in wxPython are indeed contrary to PEP 8 (because
they are the same as the names used in wxWidgets) I should point out
that nowadays the name you import is "wx".

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
------------------ Asciimercial ---------------------
Get on the web: Blog, lens and tag your way to fame!!
holdenweb.blogspot.com squidoo.com/pythonology
tagged items: del.icio.us/steve.holden/python
All these services currently offer free registration!
-------------- Thank You for Reading ----------------
 
P

Paul McGuire

I'm thinking you could actually have a progression
from a 1 line program up to a 50-line program. The
number 50 is kind of arbitrary, but my gut says that
by a 50-line program, you will have demonstrated
almost every useful concept.

If there is anything arbitrary here, I'd say it is your "increment
each example by one source line" constraint. This can force you to
use some bad coding practices to meet your target line count for a
given example.

Maybe try this approach: pick your top 10/20/50 language features and
develop concise examples. Then order the examples by length as a first
cut (longer examples probably *are* more complex), and then reorder a
bit to handle pre-requisites (introduce a minimum of new features,
preferably 1, per example). Overall, I'd have a tough time picking
just 10 language features to illustrate, but there are probably 10-20
basic features that will get new people onto fairly productive
ground. Pick 20 as your example count (50 sounds a bit long), and
stick to it, and then later add "20 More Little Programs" for the next
wave of examples in increasing complexity.

One other nit to pick: have your example classes inherit from object,
to get new people using new-style classes from the get-go.

-- Paul
 
S

Steven Bethard

Paul said:
I ***love*** this "10 Little Programs" idea! As soon as I get a
breathing space, I'm going to add a "10 Little Parsers" page to the
pyparsing wiki!



Really? Underscore-separated words preferred over camel case? What
is the rationale for this?

Rationale? It's a style guide. There is no rationale. ;-)
If we want to just say "well, PEP-8 says such and such," I think this
is an area where the thinking has possibly evolved since 2001.

I really don't think so. If anything, it's gotten more strict. PEP 8
used to allow either camelCase or under_scores. Now it only allows the
latter.
I guess pyparsing with its mixedCase functions and attributes is
doomed for the Dunce Corner. Too bad for BeautifulSoup, cElementTree,
and wxPython that are also at variance with this canon of Python
coding style.

Many (if not all) of these modules were written before the most recent
incarnation of PEP 8. Thus, they fall under the second good reason "to
break a particular rule":

(2) To be consistent with surrounding code that also breaks it

Of course, for new code, such as that in this thread, there's no reason
to break from the PEP 8 guidelines.


STeVe
 
P

Paul McGuire

Out of curiosity, how does this style jibe with the latest embracing
of Unicode identifiers? Ever tried to type an underscore on a non-US
keyboard? I have a heck of a time finding/typing the '_' character
when I visit our clients in Germany, but this may just be my own
personal Amerocentric issue (I also get messed up by the transposition
of Y and Z on German keyboards, but my German colleagues
understandably are not bothered by it). For someone already familiar
with that keyboard layout, is typing an underscore any more difficult
than my pressing Shift-_ on my US keyboard?

-- Paul
 
P

Paul McGuire

Out of curiosity, how does this style jibe with the latest embracing
of Unicode identifiers? Ever tried to type an underscore on a non-US
keyboard? I have a heck of a time finding/typing the '_' character
when I visit our clients in Germany, but this may just be my own
personal Amerocentric issue (I also get messed up by the transposition
of Y and Z on German keyboards, but my German colleagues
understandably are not bothered by it). For someone already familiar
with that keyboard layout, is typing an underscore any more difficult
than my pressing Shift-_ on my US keyboard?

-- Paul

Steve, sorry for going so far off-topic. I've started a new thread on
my questions about this aspect of PEP-8, and if there's more to say
about this, people should post it there.

-- Paul
 
B

BartlebyScrivener

------
parentRabbits, babyRabbits = (1, 1)
while babyRabbits < 100:
print 'This generation has %d rabbits' %
babyRabbits
parentRabbits, babyRabbits = (babyRabbits,
parentRabbits + babyRabbits)

------
# def defines a method in Python
def tax(itemCharge, taxRate = 0.05):
return itemCharge * taxRate
print '%.2f' % tax(11.35)
print '%.2f' % tax(40.00, 0.08)

For the person new to programming (doesn't come from C or other
languages), I think you need to add a separate explanation of string
formatting and how it works, or at least add a comment that tells them
you are using string formatting so that they can search and find out
how it works. If your aim is to teach simple programming concepts, why
confuse them so early on with fancy interpolation?

Something like

# uses Python string formatting
# http://docs.python.org/lib/typesseq-strings.html

but really I think it will just be a distraction

rd
 
S

Stef Mientki

Steve said:
I've always thought that the best way to introduce new
programmers to Python is to show them small code
examples.
This is really a nice piece of missing Python.

Sorry I didn't follow this thread accurately,
but have you considered to produce an example environment like in wxPython ?

The wxPython demo program is written as an interactive tutorial,
with a few hundred examples, nicely ordered in groups.
The user can view the demo, the code and the help text.
The user can also change the code and see the results right away.

It would even be nicer, if everybody could drop her/his examples
in a standard way, so they would be automatically incorporated in
something like the wxPython interactive demo.

cheers,
Stef Mientki
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,982
Messages
2,570,185
Members
46,738
Latest member
JinaMacvit

Latest Threads

Top