[Edu-sig] Python promises a revolution

[Kirby Urner]

At 11:01 PM 2/20/2003 +0000, Michael Williams wrote:

>A bit of both. We've only got four half-day sessions to cover the
>exercises in the handbook *and* a more substantial problem, so
>anything we can comfortably lose without sacrificing useful background
>we do. OOP is a sufficiently discrete topic that we can either take it
>or leave it. So it's not just that it's hard, but also that it's big.
>I think the procedural paradigm is much more graspable and intuitive
>to our students, who are used to working through iterative calculations
>by hand. Doing OOP properly would add at least a half-day (and probably
>more if we did it properly) to the handbook.
>
>And you're right about its limited applications in Physics. None of
>our exercises are best-solved using the OO paradigm, and we think
>they're reasonably representative of the day-to-day numerical methods
>grunt work of a physicist.
>
>Of course in an ideal work we'd cover other applications that do lend
>themselves to the OO approach, such as modeling solid state systems.
>You win some, you lose some ;->
>--
>Michael


Yes, I can see where you'd need to be realistic about the time
constraint.  In some hypothetical future, students will be more
prepared with a language coming in, because of this idea that
computer languages provide an alternative algebra for learning
maths (I liked your apology for the 'math' module -- US English
spelling i.e. a singular instead of a plural noun).

Given the favorable press, that computing with objects is supposed
to let you think more in terms of the problem domain, than in
artificial terms imposed by the computer, it'd seem tempting to
talk more generally about physics as a search for generalizations
in the face of many "black box" objects (e.g. atoms), the inner
workings of which we may probe and model, to build up a sense of
what the properties and behaviors might be.

   >>> from atoms import Atom, Neutron, Proton

   >>> v = Atom(p=7,n=7)
   >>> v.name()
   Nitrogen-14

   >>> v = v + Neutron  # hit by cosmic ray
   >>> v = v - Proton   # proton goes flying

   >>> v
   Carbon-14
   >>> v.radioactive()
   True
   >>> v.halflife(unit = 'years')
   5700

A reason for talking about objects even in an intro course is it
gives you access to generalizations about the Python primitives
and helps explain the object.method() or object.property syntax
that one typically uses, even when not defining classes of one's
own.  E.g. given we're likely to talk about the differences among
arrays, dictionaries, tuples, it makes sense to probe them as
"black boxes", using dir().

   >>> dir({})  # list guts of {}-object (dictionary)
   ['__class__', '__cmp__', '__contains__', '__delattr__', '__delitem__',
    '__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__',
    '__gt__', '__hash__', '__init__', '__iter__', '__le__', '__len__',
    '__lt__', '__ne__', '__new__', '__reduce__', '__repr__', '__setattr__',
    '__setitem__', '__str__', 'clear', 'copy', 'get', 'has_key', 'items',
    'iteritems', 'iterkeys', 'itervalues', 'keys', 'popitem', 'setdefault',
    'update', 'values']

I just thought of a good way to introduce the new 'set' type
(new in 2.3).  Use it to find what methods are common to lists
and dictionaries (or any two primitives), vs. what methods are
unique to each.  set primitives will make this easy.

Kirby