The login process was pretty smooth at PSU. On first login,
they're asked to change passwords.
I kept harping on their needing to not forget the new passwords,
but of course it's the user names, not the passwords, they're
likely to lose.
It's all coming back to me now (I've taught this class, or one
like it, before).
I got to park blocks way early, visiting Libyan coffee shop
to get a some "joe" and the time of day (of all days to leave
my cell phone at home...). Took the bus 14, then hopped
a light rail to get closer. PSU is right in downtown Portland.
I decided to spend really quite a bit of time on the 1/2 == 0
business, still using Python 2.6.
Why?
In part because showing them how to get an answer of 0.5,
without doing the "from __future__" trick, is a great segue
into talking about types, i.e. to have an answer of 0.5, enter
something like: 1.0/2 1./2 1/2. or 1/2.0 or even 1.0/2.0
This leads directly to querying some named object as to
its type.
First go over assignment of names, using the assignment
operator, e.g. a = 2, then ask for the type of a -- type(a) --
to get <type 'int'>.
I consider "type awareness" sort of the alpha and omega
of this kind of computer programming (yes, being vague
about "this kind").
After yakking about both ints and floats, it's time to
introduce strings, which makes the learning curve go
steep like a rocket. So much to do with strings.
I got into palindromes, and string reversal. Had to ask
if anyone knew about Napoleon. One student did, gave
us some history. It's that old "able was I ere I saw elba"
back story, purely fictional. I want to talk about
Napoleon again soon, in connection with The Turk,
the first chess playing automaton (or so Napoleon
supposedly thought he was playing, when he lost to
it -- if true, that coulda been traumatizing on some
level eh?).
Before getting to all that stuff about strings though,
I was into telling other stories. Guido naming the
language after Monty Python (whom most had
heard of -- also looked at xkcd) and then getting
DARPA funding to write IDLE: a good way to
introduce IDLE itself, which we're using.
These are Windows XP boxes and IDLE tends to
work OK on those. It's a disaster on some versions
of Mac though, found that out at STScI.
Steve Holden, PSF chairman, is raising this question
in the community: is it time to retire IDLE, remove
it from the standard library? Does it hurt Python
more than help it at this point?
Anyway, I like to tell stories. If you ever wanna track
down the 52 minutes of me on Blip TV, from the
International Room of a Hyatt Regency near O'Hare
in Chicago, you'll find me plotting "lore" and "technical"
as orthogonal axes, with a kind of "opportunity cost"
curve representing finite bandwidth and a freedom to
keep varying the mix.
Get really technical for awhile, then go back to
sharing lore, then gradually add in more skills
building...
We went on to function defs, which gets into indentation
heavy duty -- and the story of how Python is *not* a
curly-brace language.
I talked about the XO and OLPC, about Sugar, showed
a favorite picture. I talked about the downward pressure
the XO had exerted in the calculator market, to where
now people had these 2- and 3 hundred dollar netbooks,
though without the swivel screen the XOs had usually.
I'll keep returning to these themes over the next few
days I'm pretty sure.
We did quite a bit with the arithmetic operators, but
so far not an excessive amount. "Using Python as a
calculator" (interactively in a shell) seems to be the
"out of the box" experience many of us expect to
start with. Good segue to Sage I would suppose.
One kid went 2**2**2**2**2.. **2 a few times, which
quickly maxed out computer memory.
Another kid hacked into his laptop at home, ran
Python there or some such. This is a school that
attracts some of the freakishly gifted and otherwise
weird. My job is to keep it all moving right along.
Lots of chatter about the C language, which several
of these students have tackled already.
I brought up APL and J as in some ways "other end
of the spectrum" (way alien) so they could appreciate
how different computer languages can be. On the
other hand, Python and APL have quite a bit in
common too (especially when you add in numpy).
I talked about Scheme and LISP and how these
would have been your languages at MIT if just
starting into computer science. Python has joined
that list of elite languages (presuming one looks up
to MIT, which by this time I've linked to OLPC, so
at least there's some credibility there).
The function I most wanted to have them define
would eat any string and return the same string in
reverse. This is fun for playing with palindromes.
They'll probably dream about it tonight (I know I will).
One kid, who also asked about SSL (secure sockets
layer), a 7th grader, found out about "join" just by
browsing docs in a hurry (and asked them to shoot
for a solution out of the blue).
A solution is like:
def rev ( s ):
mylist = list ( s )
mylist.reverse( )
return "".join(mylist)
Having already worked on s.capitalize( ) and
s.title( ), both of which return strings while leaving
s unchanged (how strings are), coming upon
mylist.reverse( ) is a bit of a show stopper. You
mean some methods actually change an object
"in place"? Change it's state? No copies, no
output? No "back up"?
That's right.
This is one of the things a functional programming
purist might most hate about OO in general,
Python in particular: there's so much state,
and so much changing of state.
Some objects return (give birth, remain unaffected),
others morph before your eyes. How might any
of this be pure logical, versus too messy-biological?
My thought on that is OO is aiming to mirror the
real world and the real world is messy in this way
too. Logical abstraction only gets us so far in the
OO model.
FP promises to free us of state. The Great Lambda
tribe to the north of Python Nation, sees our little
iconic lambda, and thinks about rescuing us from
ourselves. "Liberate them from state" think our
would be rescuers.
The final activity was saving lesson1.py containing
this rev function into site-packages. We'll pick
up with it tomorrow, by the end of which I'm
hoping to have crafted a Snake class already,
using __rib__ syntax (special names).
Getting this bit in pretty early helps clear up some
of the mystery as to why dir( object of some type )
keeps dumping lists of names looking __like__ __this__.
Doing a snake class with __repr__ and __init__ starts
to clear that up. Showing off __add__ and __mul__,
maybe as some Integer Modulo N type of object,
might even further lift the veil.
I talked quite a bit about "dot notation" in general
terms, suggested that Python is a great gateway to
myriad other languages, in that how it uses dot
notation is common to all of them. We imported
the random module and started playing with
randint, shuffle and choice. One student demanded
to know how to reset the seed, but I bravely
suggested we'd postpone that discussion, but he
was most welcome to study the docs.
Kirby
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
