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