[Edu-sig] Python for Beginners

[kirby urner]

On Sat, May 24, 2008 at 10:29 AM, John Posner <jjposner at snet.net> wrote:
>>
>> I think in an Intro to Programming course featuring Python or
>> not, it'd make sense to talk a lot ...
>
> I suggest talking a little, not a lot. Your note about "Let" is good. How
> about just a short explanation that in algebra (the context in which most
> students are likely to have encountered the concept of a variable), we make
> *declarations of truth*:

My style drives some students crazy so I hope my reputation precedes
me, such that those wanting less "flitting about" feel forewarned and
pre-filtered.

Sometimes I believe in YouTubes doing the talking, or something similar,
i.e. I like those "soothing voice" animations that just take you through
it, "assignment through the ages" or something like that.

10 minutes should about cover it, except we might want to sample
alternatives (film majors).

'Warriors of the Net' a good example, for teaching about TCP/IP to
newcomers.

Of course I think everyone should know about TCP/IP, so make sure
to include that if I think students might need it (OK, at Intel they
mostly don't, but I'm a Saturday Academy instructor these days,
only see Intel people at PORPIG meetups and like that, hi Dylan).

>   x = 12 + y
>   the value of x IS EQUAL TO the value of the expression "12 + y"

Yes, more like x == (12 + y) in Python (with parens for clarity).

>
> ... whereas in computer programming, we *give instructions* to the computer:
>
>   x = 12 + y
>   LET the value of x BE EQUAL TO the value of the expression "12 + y"

Except we also have "x == y" and "x is y" in Python, with "x == y" mapping
to a __rib__ in x (optionally absent in the more general case), i.e.
x == y calls x.__eq__(y)  http://docs.python.org/ref/customization.html

This is worth mentioning as that leaves the door open to "==" meaning
something quite alien, in the hands of a perverse programmer, whereas
"=" (assignment) and "is" (memory id comparison) are much more
hard-wired.

>
>> ... about this new use of the
>> equality symbol ( = ) and how language designers have felt
>> about it (suspicious in some cases).
>
> I suspect that students in an Intro to Programming course couldn't care less
> about what the language designers thought. Language comparison in an intro

Well, if this were Princeton, the profs couldn't care less what
students thought,
as the profs were the experts and thought we all needed Assembler, FORTRAN,
PL/1, SNOBOL, APL and a little LISP, all in the same intro course.

I liked APL best, and continue to like J (a next incarnation), given my druthers
would mix a little J teaching with my Python teaching, just to remind students
of the big playing field they're playing in.  [ I need more time
learning from J
teachers though -- not an O'Reilly langauge, so nothing in Safari ]

The LEX Institute in Japan an influence here, in persuading me to not
get too mono-lingual.

> course is more likely to be confusing than enlightening. How many high
> schools teach French and Spanish in the same course?

Cite LEX again.  Not saying everyone should do it my way, or that your
way is wrong.  We each cultivate a style -- like circus acts.  Very boring
if everyone is a clown.

I'm sure a few Intro to Programming teachers besides me still take a
multi-language approach.  In that case, it's not a course goal to be
blackbelt in any one language when finished.  It's just a survey course.

Lots of eye-candy up front, a best foot forward kind of thing.

Physics uses the same techniques, the Intro course featuring lots of
demos, falling stuffed monkeys shot by projectiles with parabolic
trajectories, woo hoo.

At Princeton a lot of us were liberal arts majors, making a pilgrimage
to the far Equad out of curiosity, not out of obeisance.  The profs
knew this might be our one and only exposure and didn't want us
to leave without overview.

That's what Intro courses tend to be good for:  recruit a lot of
non-majors and don't disappoint them, plus find the few who want
to go deeper (I stuck around for more, shifted more to computers
later, via McGraw-Hill, home of Byte Magazine).

>> Post-its also have this problem of needing to be physically
>> connected to things (that's the hallmark of post-its, they
>> stick to stuff).
>
> You can't convince me that John Zelle's sticky note metaphor is anything
> other than *fabulous*: they're different from objects, but are attached to
> objects; they can be easily removed from one object and attached to another;
> they can be destroyed without affecting the objects to which they were
> attached.

I'm fine with *fabulous*.

I think in a textbook you don't want too many metaphors flying around.

I'm more oral tradition / cartoonist and apply many metaphors thick
and fast, with an eye toward building up that more generic impression,
of names on the one hand (organized namespaces), memory and/or
math objects on the other, with name : object relationships the glue,
like key : value pairs in a Python dictionary.

> My only complaint is that John doesn't use the metaphor *more* in his
> textbook! :-)
>

Yes, sometimes one wishes more graphical content in general, and
metaphors like post-its are valuable in that way.  But the trade off
between graphics and words is a fine tuning, depends on what kind
of book.

O'Reilly's 'Head First' series is a different style, the 'Dragonology'...
'Wizardology' series yet different again.

My style of teaching CS concepts is more Narnia than Bourbaki,
with post-its somewhere on the spectrum.

>> When I go y = x in Python, it's like x emailing a web address
>> to y.
>
> Um, it's *way* more like attaching a sticky note to a physical object.

Per your point with the post-its, I think we agree that a main thing
to get is "del y" removes the *name* y from the namespace.

Deallocation of memory objects is more rightly the job of the
garbage collector.  "del y" impacts the referenced PyObject in
that the latter's name counter goes down.

>> (what true beginners are likely familiar with, given
>> at least minimal GUI-based file management experience)
>
> That's a "true beginner"?

Yes, in this day and age, a beginner has probably used a
computer since early childhood, likely has dragged and
dropped files with the mouse for years prior to any
programming class.

The move and copy options are probably as engrained
from the menus, as salt and pepper or chocolate and
vanilla in a goodly portion of today's student body.

When we go x = y, x and y dock for a sec, and a payload
goes from y to x, like an URL, or a remote, a controller.

The copy is likewise disposable, and y will not ask for it
back, or shouldn't have to, because y keeps its own copy,
it's own relationship with that snake-like thing with __ribs__
(the number 8 for example).

>
>> Either way x = y might come across as "static through time"
>> in some way, whereas in many computer languages (I'm not
>> saying all), we're talking about a quick happening, a few
>> nanoseconds or clock cycles, then it's all over.
>
> Nope, the sticky note remains attached to the object for a considerable
> period -- until it's removed from that object and placed on another one.

But x and y have no lasting relationship.  For a split second,
they're coupled, in that x needs a copy of y's URL, the pointer
to the object.  Then they go their separate ways *immediately*.

Going "del x" doesn't create any ripples for "y" or vice versa,
except insofar as the shared object registers the change.

I think it's second nature to think this way in programming, because
we're thinking "instructions in sequence".  But in a math book it's not
always so clear what the time scope might be, or even if there is one.
Mathematicians get more slack, don't have to garbage collect so
assiduously.

> [ ... or until the naming scope disappears. John Zelle, do you include this
> situation in your sticky-note metaphor? Could sticky notes *of a particular
> color* or "with a particular shape* indicate the names in a particular
> scope? ]
>
> -John Posner
>
>

Kirby