For Experienced Programmers

HOW PYTHON IS DIFFERENT
Comments for those with prior programming experience
Bruce Sherwood, Fall 2006; revised Fall 2009
(For more formal comparisons, see Google)

In many respects Python is like any other algorithmic programming language
(C, Pascal, Java, etc.) and unlike, say, Lisp. There are a few features
of Python that an experienced programmer doesn't expect because they
are embedded in a seemingly familiar environment yet are quite different
from most algorithmic languages. This document attempts to point out
the most important ones.

DYNAMIC TYPING
When you say "z1 = Zork(cost=23)" you create a Zork object
and stick a label on it, "z1". There is no need (and no way)
to declare "z1" to be of type "Zork" before labeling
this instance of the class "Zork" with the label "z1".

If you now say "z2 = z1" you have not created any new object,
you have merely stuck a second label "z2" on the existing Zork
object. Note carefully that this does NOT create a second instance of
the class "Zork". If you alter z1.cost it is just the same
as altering z2.cost. Making a second, independent copy of an object is
a fairly unusual thing to do in Python, but there exist special methods
for doing this.

If you now say "z1 = 3.7" the label "z1" no longer
refers to the Zork object, and a reference counter on the Zork object
is decremented. You can still refer to the object with expressions such
as "z2.cost". If you then say "z2 = 28.7/3.4" there
is no longer any way to refer to the Zork object. The Zork object reference
count is decremented again, to zero, and the object is now marked as
eligible to be deleted by the garbage collection routine, since there
is no longer any way to refer to it.

This label behavior only applies to objects that are
"mutable" (can be changed; see next section). In contrast, if you say
"a = b = 5" and then say "b = 2", "a" still has the value 5.

Special case for VPython: Humanly visible objects such as boxes or spheres
in a graphics scene have an extra reference count so that even if there
are no labels on these objects, they are not deletable because a human
viewer counts as a reference. To delete a visual object it is first necessary
to set the visible attribute to False.

MUTABLE AND IMMUTABLE
An important Python structure is a list: mylist = [3, 'dog', 4.7, Zork(cost=23),
box()]. The 'dog' in this list can be referred to as mylist[1], the
elements being numbered starting with zero. If you say mylist[1] =
42 you've changed 'dog' to 42 in the list. The ability to change elements
in a list means that lists are "mutable".

A different list-like structure is a tuple: mytup
= (3, 'dog', 4.7) is created using parens instead of square brackets.
You can read an element, so mytup[1] refers to 'dog', but you cannot
change an element. A tuple is "immutable". The only way to achieve the effect is something
like this: mytup = (mytup[0], 42, mytup[2]), which creates a new
tuple.

Lists and tuples are examples of what are called "sequences" in
Python. A third important kind of sequence is a dictionary, which is
a container of elements with keywords, and you index in not by position
but by keyword (as a string).

"FOR" LOOPS
A particularly delightful and powerful feature of Python is that you
can loop over any sequence. Suppose for example you have created objects
for the planets. You can loop over them like this:

INTEGER DIVISION
As in many languages including C, 3/4 normally evaluates as zero rather
than 0.75. There is a slow migration path for Python eventually to
treat 3/4 as 0.75 rather than zero. You can invoke this behavior now
by making the following statement the first statement in the program:

from __future__ import division

Note carefully that there are TWO underlines before "future" and
TWO underlines after "future".

IDLE VS SHELL
If you run Python directly, or operate in the "shell" window
of IDLE, the editor that comes with Python, you can execute statements
interactively. Many experienced programmers find this a useful mode.

Some people much prefer to write whole programs,
even small ones, because it is easier to revise and easier to understand
what state of module import one is in. There are two features in IDLE
that can be set in the Configure IDLE menu option (if not already set
at install time) which make edit/compile/run/revise cycles almost as
immediate as the shell window. One feature is to specify that whenever
you press F5 to run, the current version of your file is automatically
saved to disk ("autosave";
note that there is nearly infinite un-do available). The other is an
option to specify that at startup IDLE should open an edit window rather
than the shell window (you can always open a shell window later, and
one is created when you run a program, because that's where text output
goes). The first time you press F5 to run, you will be asked to specify
where to save the file, but with autosave turned on you won't be asked
again.

The effect is that when you start IDLE you're ready to enter a program,
and after the initial save, the programming cycle is extremely simple:
just press F5 to save and run. One-touch testing.

(As of Fall 2009 the VIDLE variant of IDLE lets you specify
that you don't need to save the file even the first time. If you exit
VIDLE without saving the file to a permanent location, you're invited
to do the save. With this restoration of a feature that used to be present
in IDLE, you can now write little test routines without the distraction
of saving the file. It is expected that the standard IDLE distributed with
future versions of Python will incorporate the recent improvements currently
available in VIDLE.)

For a more powerful interactive environment, you might be interested
in ipython.