On 02/08/2014 07:45, Mark Summerfield wrote:
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.
Entirely agree. Please raise an enhancement request on the bug tracker
if there isn't already one.
Suggestion #2: Make all the turtle examples begin "from turtle import *" so no
leading turtle. is needed in the examples.
I'm not so sure about this, but raise an enhancement request and see
what happens. Worst case it gets rejected, best case it gets accepted,
implemented and patch applied.
Suggestion #3: Make object(key=value, ...) legal and equiv of
types.SimpleNamespace(key=value, ...).
Haven't the faintest idea and too lazy to find out :) I suggest follow
advice from #2.
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.
Finally I believe there's a very strong chance that of of this will be
taken on board. I've noticed activity on the bugtracker recently
regarding turtle, GSOC student maybe?
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
