Nick Coghlan wrote:
> André wrote:
> > So, students will be able to write:
> > pete = CreateRobot(2, 3)
> > pete.move()
> >
> > learning about objects and methods.
> >
> > As for things like
> > for robot in robots:
> > do stuff
> >
> > that will be for my use only: drawing robots on the screen,
updating
> > the 'world' when robots pick stuff up, etc. My intention is that
the
> > students will use the EXACT python syntax, so that they don't know
that
> > *I* have given a *name* to their robot(s) behind the scene.
> > I have to cut this short; I hope it clarifies my intentions.
>
> My (and, if I understand him correctly, Jeremy's) concern would be
that error
> messages like "Robot 'pete' has hit a wall!" would give students the
impression
> that the robots automatically know their name as a result of the
assignment. In
> standard Python, that simply isn't true.
>
It was not my intention to reveal that I had assigned a 'name' to the
robot; it was only for internal purpose. (However, see below)
> If, instead, CreateRobot looked something like:
>
> def CreateRobot(street, avenue, name=None):
> if name is None:
> name = "Robot" + Robot.getNextNumber()
> return Robot(street, avenue, name)
>
>
> Then, using a simple assignment:
>
> pete = CreateRobot(2, 3)
> pete.move()
>
> Would give an error like:
>
> "Robot1 has hit a wall"
That might be an excellent way to solve my problem.
>
> This could then be used to point out that objects named using
assignment don't
> know about the names they have been given, and need to be told:
>
> pete = CreateRobot(2, 3, "Pete")
> pete.move()
>
> "Pete has hit a wall"
>
> Instead of misleading the students ("objects know what names they
have been
> given"), you have taught them a powerful truth - objects and the
names you give
> them via assignment are entirely independent.
Good point.
>
> It also directly addresses the question of aliasing. Think about how
Steven's
> modified dictionary would react to this code:
>
> pete = CreateRobot(2, 3)
> dad = pete
> dad.move()
> pete.move()
>
> Internally, idioms like "for robot in robots" should be entirely
unaffected -
> the registration of the robot instance with the global list of robots
can be
> handled by the robot initialisation method.
>
You make some excellent points. What I implemented (last night) was
the "code pre-processing" suggestion. Instead of simply "exec"uting
the code, I changed it first so that statements like
pete = CreateRobot(2, 3)
john = CreateRobot()
albert = CreateRobot(colour="blue")
get translated to
pete = CreateRobot(2, 3, name="pete")
john = CreateRobot(name="john")
albert = CreateRobot(colour="blue", name="albert")
I just checked with:
pete = CreateRobot()
dad = pete
dad.move()
pete.move()
and I got (I haven't implemented the gui part of dealing with multiple
robots)
==
robot pete move()
robot pete move()
==
which worked the same way as your method would (except with "pete" as a
common name instead of "Robot1").
[As an aside, it was an *interesting* experience to learn enough about
regular expressions to do this.]
Now, after reading your post, I realise that I would have to deal with
the problem of figuring out how to handle cases where the users has
already given a name to the robot. Your solution takes care of this in
a very simple way.
Furthermore, I could probably base a lesson around it, about how
instances have no name.
Thank you very much for your suggestions.
André
--
http://mail.python.org/mailman/listinfo/python-list
