Intro to Python

as (to be) presented to TCS Programmers' SIG

2002 October November

Notes about this Presentation

What is Python?

Where can I run Python?

In a fairly broad range of environments.

How can I run Python?

Why might I want to use Python?

An incomplete list...

Philosophy and Design style of Python

Attempts to keep number and complexity of features manageable for users,
while providing what users need and want.

Slogans, semi-official and unofficial:

Perl: "There's more than one way to do it."
"There's more ways to do it than you can remember, probably more than you can even recognize."
Python: "There should be one -- and preferably only one -- obvious way to do it."
At least we tried to pick the right way.
(I have seen a progenitor of this remark attributed to Dijkstra: "I thought that it was a firm principle of language design--out of concern for programming as a human activity--that in all respects equivalent programs should have few possibilities for different representation [...]. Otherwise completely different styles of programming arise unnecessarily, thereby hampering maintainability, readability and what have you. This requires from the language designers the courage to make up their minds!" - Edsger W. Dijkstra on GREEN, an early version of Ada)


Extreme orthogonality is when everything is as consistent as possible even if it's different. :-) For example, LISP seems to want everything to be lists, and for the calling syntax to be the same for all features, i.e.
(FUNCTIONNAME param1 param2 ...)

         ; LISP: do something with the 2nd item in array.
         (do-something-with (aref myarray 2))
For readability and terseness (and maybe for typechecking?) some people might prefer the code
         // C/C++: do something with the 2nd item in array.
or the code
         # Python: do something with the 2nd item in array.
even though it is less consistent: accessing an element of the array does not use the same syntax as calling the function do_something_with does.

On the other hand, the rejection of orthogonality in favor of terseness can be taken rather far. For example, Perl (which for most of the popular history of the WWW has probably been the most-used scripting language for generating webpages) has an amazing number of special uses of special characters and special variables in special circumstances.

      while (<>) {   # A Perl programmer is expected to remember
                     # that the default input to the line-input operator <>
                     # is STDIN, and that the default place for a line
                     # of data that was read in to be stored is $_.
          if ($_ > 0) {
          if ($_ =~ /^\s+(\w+)/o {
                # =~ is the pattern match operator.
                # // surrounds a pattern.
                # In a pattern match, ^  indicates the beginning
                #                          of a line or of the string, depending...
                #                     \s indicates whitespace.
                #                     +  indicates repeated one or more times.
                #                     \w indicates a letter, numeral, or underline.
                # $1 is the string matched by the first substring surrounded by ()
                #   within the pattern match.
Perl is probably second (third?) only to Intercal and APL as languages likely to be mistaken for line noise. It often does permit extreme terseness.

For readability, some people might somewhat prefer the Python:

        import re  # for regular expressions package.


        pat = re.compile(r'^\s+(\w+)')  # This regexp syntax standard is Perl's fault, or to Perl's credit.
        while 1:                        # Python won't let us do variable assignment
            iline = raw_input()         #   within a conditional, to prevent accidental = for ==.
            if raw_input > 0:
            matchobj = pat.match(iline)
            if matchobj != None:

The Python is longer, but to a novice it would be more readable. Some lessons we can take from this? Admittedly, it's well-known that regular expression matching is almost an area of obsession with the designers and many users of Perl. It's not surprising that the Perl code is shorter. But it's far too easy to write Perl code that's not readable except to a fanatic, with its weird proliferation of special cases and weird character meanings.

[I don't think this regular expressions example is all that good, so I didn't give it much time in the actual presentation.]

...Why might I want to use Python? (Cont'd.)

Easy and quick to write, easy to read.

'It's only a bit slower than Perl.'

Some rudiments of actual Python code

Hello world.

  # "Hello, world" program.
  print "Hello, world."

(Relatively) simple built-types.

Data Structures

What ones are there?

Control Structures

What ones are there? Most are what many seasoned multi-lingual programmers might expect.

Higher-Level Code Organization

Other topics not covered in detail here.


Error handling

Other Very Special Topics and Links

The website is a great resource. It includes Guido van Rossum's Python Tutorial.

Python Warts, by A.M. Kuchling

"While I think Python has a very elegant design that successfully straddles the fine line between the minimalism of Lisp and the rococo complexities of Perl, it's certainly not perfect. There are various design features that are ugly, or at least suboptimal in some way. This essay will examine the most significan problems in Python, as I perceive them, assisted by suggestions from the comp.lang.python crowd."

A Python/Perl phrasebook, by Jak Kirman

© Copyright 2002 by Chris Niswander. All Rights Reserved.