[Edu-sig] spinning 'self'

[kirby urner]

On 8/13/07, John Zelle <john.zelle at wartburg.edu> wrote:

> I would quibble about self not doing any work (you need it to access its
> attributes), but I understand the point you are making. Again, though this
> makes things seem a bit more mysterious than they really are. The self
> parameter is a placeholder in the exact same sense that all formal parameters
> are place holders for objects that are provided at call time. The self
> parameter has no 'specialness' in this regard.

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 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__.

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).

> Yes, otherwise you incur the wrath of the Python Gods. Deviation from self
> appears to be  the one form of heresy that is never tolerated under any
> circumstance. "To thine self be true!"

But yet the Python interpreter has no problem with:

"""
Simple definition of a Coupler
"""

from math import sqrt


class Point:

    def __init__(me, x = 0, y = 0, z = 0):
        me.x = x
        me.y = y
        me.z = z

    def __repr__(me):
        return 'Point at (%s, %s, %s)' % (me.x, me.y, me.z)

    def distance(me, other):
        return ( (me.x - other.x)**2 +
                 (me.y - other.y)**2 +
                 (me.z - other.z)**2 )**.5

# globals:
A = Point(1,0,0)
B = Point(0,1,0)
C = Point(-1,0,0)
D = Point(0,-1,0)
E = Point(0,0,sqrt(2)/2)
F = Point(0,0,-sqrt(2)/2)

class Coupler:

    def __init__(me):
        me.A = A
        me.B = B
        me.C = C
        me.D = D
        me.E = E
        me.F = F
        me.volume = 1

    def rotate(me):
        # to be implemented
        pass

    def __repr__(me):
        return 'Coupler (%s, %s, %s, %s, %s, %s)' % \
               (me.A, me.B, me.C, me.D, me.E, me.F)

>
> > David Goodger was good on this in his 'Idiomatic Python'
> > at OSCON 2007 [2]:
> >
> > If your object is an iterable (i.e. has a "duck face" (which is
> > like being a "duck type" but sounds more like "interface"))
> > then address as such, as in in 'for myvar in self.__dict__',
> > and not using has_key() or some such more specialcase
> > form.
>
> Huh? I'm affraid I don't follow this. If my object (meaning self?) is
> iterable, I doubt that I intend to iterate through its namespace.  If the
> point is simply not to use keys() as the iterable sequence for a dictionary,
> whether it's self.__dict__ or any other dictionary,  that I get.

Yeah, second point -- treating __dict__ like any other dictionary,
not using keys() plus just 'if foo in bar:' not 'if bar.has_key(foo):'

> > In this same spirit (aha! another one), we just go with 'self'
> > at the end of the day.
> >
>
> And all is right with the world.
>
> --John

I like using first person pronouns for 'self' in some segments because
it helps with the OO thinking.

It's not just 'is a' or 'has a' that we want to inspire, but 'am a'.

Like Bottom in Midsummer Night's Dream:  'I am a wall'.

Kirby