If we're ever at a loss for what to talk about, in this context, of Python
teachers, I could recommend a list of default topics, one of which would
always be...
What is this 'self'?
The self appears right when we introduce the class construct (keyword
class). And then we say things like "Python provides it" or "Python fills
it in". What is "it" then? "It" is "the instance". For some, things are
starting to get muddy.
For coders familiar with OOP style grammars i.e. they're coming from
another language such as JavaScript or Java (quite different I realize),
they've got a sense of it, from keyword 'this'.
However Python is widely touted as a gateway language into OOP style
thinking, so we get a lot of first timers. We owe them a clear picture of
self.
One andragogical technique comes straight from the docs:
instance = C()
C.method(instance) # <-- needs instance as argument
is equivalent to:
instance = C()
instance.method() # <-- instance is "subject" as in subject.verb()
... of course we may add additional arguments at will, but lets keep it
simple.
In OOP, all the selves share the same template or class code, so how is
Python to distinguish one self from another?
It's not like each self is carrying around a copy of the method code. The
model is more like having DNA in common (a shared genetic core).
As in:
class Creature:
def eat(self, food): # <--- needs to know which self
self.stomach.append(food)
With:
instance.eat("spaghetti") # <-- self known to Python
we have enough info to figure out which self, and Python obligingly brings
it forward, to fill the placeholder, usually 'self'.
With:
Creature.eat(instance, "spaghetti") # self supplied by the caller
we're not giving enough distinguishing information with generic Creature,
and so instance has to be provided, as the self.
Further andragogical elaboration involves showing what I mean by "usually
'self'" i.e. self is not a keyword but a placeholder.
Here I tend to go for a Chinese character substitute, e.g. for "Ego", to
remind the learner of Unicode in addition. Emoji can't be Python names or
I might go for one of them.
* * *
Another good article by Trey Hunner just came out. He's one of the more
prolific Python teachers *that I know about* (an important caveat as I'm
always missing *a lot*):
https://treyhunner.com/2019/04/is-it-a-class-or-a-function-its-a-callable/
He takes up the issue of "callables that are functions" versus "callables
that are actually types (classes)".
That can help with fine tuning one's sense of what a "type" is, plus
callability in general is a bridge to decorators, and this article
definitely goes there.
Kirby
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
https://mail.python.org/mailman/listinfo/edu-sig
