Last week I spent a couple of days teaching two children (10 and 13 -- too big
an age gap!) how to do some turtle graphics with Python. Neither had programmed
Python before -- one is a Minecraft ace and the other had done Scratch.
Suggestion #1: Make IDLE start in the user's home directory.
Suggestion #2: Make all the turtle examples begin "from turtle import *" so no
leading turtle. is needed in the examples.
Suggestion #3: Make object(key=value, ...) legal and equiv of
types.SimpleNamespace(key=value, ...).
Explanation & Rationale (long):
They both had Windows laptops and so we began by installing Python. They didn't
know if they had 32- or 64-bit computers but it didn't matter, the installs
just worked. One child had no problem but the other ended up on the Download
page which lists all the possible Windows downloads; so we had to go back and
start again.
We discovered that IDLE's working directory is C:\Python34 -- surely this is
the wrong working directory for 99% of normal users and for 100% of beginners?
Naturally they saved all their .py files there until I realised. And then when
I got them to create a new directory for their own files ("Python" and
"pie_thon") and dragged them across they also managed to move python.exe and
pythonw.exe.
Couldn't IDLE start in the home directory?
The turtle package is quite nice and there is a very short but dramatic colored
star example at the start of the docs. There really ought to be a little
gallery of similar examples, including circle, polygon, and star (yes I know
circle and polygon are built in but it is nice for children to see a simple
implementation), and of course a few more -- but not any that compose shapes
(e.g., face and house), since one would want them to learn how to compose
themselves.
Making them type turtle.this and turtle.that would be torture, so we began
every file with
from turtle import *
I wish the doc examples did the same. (For randint we did from random import
randint since only the one function was needed.)
I stuck to pure procedural programming since OO would have been too much
cognitive load to add given the time. I did make sure that once they'd created
something (e.g., a face), they then put it inside a function.
However, when it came to making a game ("hit the hippo") we needed to maintain
some state that several functions could access. (I had to gloss over that we
were doing higher order programming! -- e.g. onscreenclick(goto) etc.) What I
wanted to write was this:
state = object(moving=True, score=0) # Illegal!
...
state.moving = False # etc.
But was forced to do this:
state = {'moving': True, 'score': 0}
...
state['moving'] = False # so they get confused between {} and []
There is an alternative:
from types import SimpleNamespace
state = SimpleNamespace(moving=True, score=0)
...
state.moving = False # etc.
But I felt that explaining what a namespace was would be too much -- remember
they're having problems remembering to put () at the end of function calls etc.
It would be nicer if object() acted as it does now but object(key=value,...)
behaved like types.SimpleNamespace.
--
https://mail.python.org/mailman/listinfo/python-list
