[ after two consecutive trips to Winterhaven as younger daughter,
like older sis, is studying theater but forgot her script... -- KU ]
> > Yes, I agree. What's special about 'self' is simply what you mentioned
> > above: it gets passed "silently" and you need take special care to have
> > a variable (usually 'self') ready for it as the first parameter of your
> > method definition -- but then don't mention it when you call in (' self '
> > is "implied" -- what makes it special).
> >
>
> But this is exactly my point. Self is _not_ passed silently. The actual
> parameter is right there in the call: obj.someMethod(actual1, actual2). obj
> _is_ the parameter. The only difference is that it's not inside the parens
> when the call is made (unless you use someClass.someMethod(obj, actual1,
> actual2, which makes my point even more directly). Self in the method
> definition is not at all special. Rather it's the calling syntax that's
> different. And the simplest explanation for the different form of call
> syntax the fact that it's dispatching a method based on the type of obj
> (although I wouldn't use that terminology for beginning students).
Well, I'd say 'self' is loudly whispered then, and caution against calling
the object in noun.verb(params) a "parameter" of said expression. To
the interpreter maybe, but not to verb( ). Or if it is a param, then it's
"special" simply for *not* being listed between the parens.
I typically teach seeing foo( ) as "a thing with a mouth" as "( )" has the
appearance of "lips turned sideways" (emoticon style) and their function
*is* actually to signal intake of the contents, to some internal scope
(a local namespace).
But why not see foo( ) as "a thing with an ear" instead? Makes sense.
We'll maybe get to nose later.
NOTE: I don't teach that return returns poop except in purposely scatalogical
treatments (per my Europython 2007 slides). No, a function returns the fruits
of its labor, its work, which one can objectify and return as a gift
(I hear the
Freudians cackle), as a referent (the return object). The "landscape" wherein
all this "work" is getting done we call "memory" or sometimes "the heap"
(just think of a junk pile).
So I see 'obj.name(params):' as a case of obj "loudly whispering" its
identity into its own ear, where there's suddenly a parameter waiting
to catch it, even where the *caller* had no clue (it's what "heard the call"
that "already knew"):
>>> class Foo:
def __init__(self, name):
self.name = name
def checkid(self, other):
return id(self) == id(other)
>>> myguy = Foo('Joe')
>>> myguy.checkid(myguy) # caller needn't know self id, cuz myguy
already knows it
True
>>> mygal = Foo('Jane')
>>> mygal.checkid(myguy) # mygal knows she's not myguy, despite being same type
False
> > But the purpose of 'self' comes into its own when you have a million
> > 'selves' (or just ten) all instantiated from the very same class
> > definition.
>
> > Then we start to appreciate how each of those million has its own
> > state, its own anchor in memory, thanks to 'self' (or whatever) and in
> > turn self.__dict__.
>
> OK, so objects have state. That's an important part of OO, but again, I don't
> see any particular tie to the "magic" of self. Perhaps I'm reading too much
> into what you are saying, but it seems like you are somehow trying to tie OO
> into some "deep" truth or grand insight into the notion of self, perhaps in
> the sense of self-reference and self-knowledge. At least that's what your
> musing on the different points of view presented by renaming self seem to
> suggest to me. I would emphasize quite the opposite: The _mechanisms_ of OO
> are quite straightforward, mundane actually, and not at all amazing or
> mysterious.
I think I'm going for a mark between these extremes. I get students deeply
suspicious of engineering in general, cynical about engineers as cold fish
who build ugly killing machines (Quaker schools remember).
They already know we see humans in OO terms in games like Sims, so
there's no use denying it. Sims is easy to diss if you think it teaches
that humans are mere automatons, predetermined by fate, mere
automatons and yadda yadda (the usual BS).
With Python, I want to be able to say, kind of as you do, "look, very
transparent, nothing up the sleeves, quite unremarkable, shallow (not
murky) by design".
But I also want them to feel safe modeling themselves as "things with
backbones" (where __ribs__ come together) i.e. it's not demeaning or
profane to model humans, including one's self, in these simple computer
language comic strips we call "programs" (scripts).
That feared determinism isn't really there, because everything ultimately
faces outward into userspace anyway (no namespace is ultimately
completely private or how do we justify calling it a namespace, even
to ourselves?)).
Userspace where the *real* humans are, and it's not our business to
pretend we're isomorphic to them (this is not an AI project). We're
"cave paintings," "homomorphisms," "analogies" -- very primitive, but
do valuable and intelligible work nonetheless. "We" being "we computer
programs" in this paragraph.
> Again, I might just be reading too much into what you are saying, as I
> personally have always been fascinated with the human sense of self (The
> mind's "I" as Hofstadter and Dennet put it). Having just read Hofstader's "I
> am a Strange Loop," I find myself thinking about these issues perhaps a bit
> too much.
Part of this fits into what I call "empathic programming" where we encourage
budding engineers to develop kinesthetic models of hydropower dams and
such.
"I am a dam" means feeling that restrained water, that emanating electricity,
all those frustrated fish.
They know about this in Holland: a stressed dike is stressful.
This isn't to "romanticize" engineering (although maybe it does some, as the
Romans were reputedly good at engineering, so were likely empathic, more
regarding their aqueducts and machines than their fellow humans though,
especially slaves -- personality attributes still all too prevalent).
OO fits in with this ability of pretty much anything to "have a self" (that's
part of the analogy: the type or class is what's general to all, whereas
"having a self" means "personalized" or "individuated" in some way).
> > There's nothing much else to distinguish two objects of the same type.
> > ' self ' objectifies objects, and as such isn't really called upon to play
> > its role until an object is instantiated (i.e. gains a self).
> >
> > I forgot to suggest 'I' (capital 'eye') as an interim possibility (in
> > addition to candidates ' this ', ' ghost ', ' me ') though of course that's
> > hard to decipher in ASCII (looks just like Number One).
>
> Hofstadter and others point out that there is some strange entanglement or
> loop going on when we use the terms like "I" or "me." That's the kind of
> conundrum I'd like not to have my students thinking is part of OO.
Right. Python isn't so murky.
> Again, the
> mechanisms of OO are quite pedestrian, even though we _can_ use them to build
> amazing abstraction. I say leave contemplation of "self" to philosophy and AI
> classes. For me, Python's self is just the conventional name of the first
> formal parameter of a method. Using the same name all the time allows anyone
> reading even the smallest snippet of my code to know that I am accessing an
> attribute of the object that caused the method lookup. There is nothing deep,
> mysterious, magical, or even difficult, about it. Let's not give the
> impression that there is.
>
> --John
For me, the OO model comes into better focus when I allow it to take over the
world at least interimly (while I'm programming), such that
"everything (including
me) is an object".
I'm putting a lot of emphasis on 'self' in first person terms, including other
Unicode symbols, because I'm trying to recruit new users, whatever their
pre-existing philosophies (I make few presumptions), into checking out and
using our OO mirror.
Kirby
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
