finding name of instances created

André andre.roberge at
Sun Jan 23 13:29:22 CET 2005

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,
> > the 'world' when robots pick stuff up, etc.  My intention is that
> > students will use the EXACT python syntax, so that they don't know
> > *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
> 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
> 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

and I got (I haven't implemented the gui part of dealing with multiple
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.


More information about the Python-list mailing list