finding name of instances created

[André]

Jeremy Bowers wrote:
> On Fri, 21 Jan 2005 21:01:00 -0400, André Roberge wrote:
> > etc. Since I want the user to learn Python's syntax, I don't want
to
> > require him/her to write
> > alex = CreateRobot(name = 'alex')
> > to then be able to do
> > alex.move()
>
> This is just my opinion, but I've been involved with teaching new
> programmers before so I think it is an informed one. I don't think
you
> teach a language by hiding how the language works, no matter what the
> intentions.
>
> You should be *minimizing* the magic. You're going to train your
students
> that Python objects have names (they don't) and that's going to mess
them
> up later. Actually, it's going to mess them up almost right away,
because
> how can they have a list of robots like this:
>
> for robot in robots:
> 	robot.turn_left()

They will not be able to do that.

>
> That can't work, right, the command inside the loop can only affect
the
> robot named "robot", right?
>
> You can't teach Python if what you're actually teaching them is a
variant
> that you have created that is used nowhere else on Earth, and is
> internally inconsistent to boot (see loop above, the *real* Python
> variable semantics conflict with the semantics you are teaching).
>

I think you misunderstood my intentions, possibly because I explain
things too superficially.

> Considering that not a month goes by where someone doesn't post a
question
> related to this, and it has been a FAQ entry for as long as I've used
> Python, I think you are doing a major disservice to your "users" by
> training them that objects magically gets the name when assigned. I
> strongly urge you to do absolutely no pre-processing of any kind to
the
> programs they generate. (By which I mean changes to the code; running
> pychecker on it would be OK; and I'd urge you to resist the
temptation to
> process its output, either. Provide a "translation table" if you need
to,
> but they need to learn to read the real output, too.)
>
> Programming is hard enough with burdening people with "pleasant
> falsehoods". Trust your students to handle the truth (and of course
> rationally minimize the truth they have to handle, and by using
Python
> you're off to a great start there). If they can't handle the truth,
with
> time, effort, and support, they *sure* as hell can't handle lies!

The environment in which students (my kids first, others later :-) will
learn is based on Richard Pattis's  "Karel the Robot"   (adapted for
Python in "Guido van Robot").  They are presented with a robot that can
do four basic actions, as I described in a previous post.  It's been
used successfully in many places.

The students learn first the procedural aspect of python. Here's a
quick example of a program that they can write:

.def move_and_turn():
.    move()
.    turn_left()
.
.def draw_square():
.    for i in range(4):
.        move_and_turn()
.
.draw_square()
======
At this point, they don't know anything about objects and methods; but
they will have learned about functions and variables.  This is where
'Guido van Robot (GvR)', which has been used succesfully to teach
programming using a syntax somewhat similar to python, but not quite,
stops.  (Actually, you can't use variables in GvR).

I want to move beyond that and introduce objects and classes.

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.

André