The base class:

class Constraint(object):

def __init__(self, strength):
        super(Constraint, self).__init__()
        self.strength = strength

def satisfy(self, mark):
        global planner
        self.choose_method(mark)

The subclass:

class UrnaryConstraint(Constraint):

def __init__(self, v, strength):
        super(UrnaryConstraint, self).__init__(strength)
        self.my_output = v
        self.satisfied = False
        self.add_constraint()

    def choose_method(self, mark):
        if self.my_output.mark != mark and \
           Strength.stronger(self.strength, self.my_output.walk_strength):
self.satisfied = True
        else:
            self.satisfied = False

The base class Constraint doesn’t have a "choose_method" class method, but it’s called as self.choose_method(mark) on the final line of Constraint shown above. 

My question is:  what makes "choose_method" a method of the base class, called as self.choose_method instead of UrnaryConstraint.choose_method?  Is it super(UrnaryConstraint, self).__init__(strength) or just the fact that Constraint is its base class? 

Also, this program also has a class BinaryConstraint that is also a subclass of Constraint and it also has a choose_method class method that is similar but not identical:

def choose_method(self, mark):
    if self.v1.mark == mark:
            if self.v2.mark != mark and Strength.stronger(self.strength, self.v2.walk_strength):
                self.direction = Direction.FORWARD
            else:
                self.direction = Direction.BACKWARD

When called from Constraint, it uses the one at UrnaryConstraint.  How does it know which one to use? 

Thanks,

Jen

Jen Kris <jenkris@tutanota.com> writes:
>My question is: what makes "choose_method" a method of the base class=
>, called as self.choose_method instead of UrnaryConstraint.choose_method?

You can see that in the following code "b()" is called on the object
"self" in the base class "A", even though there is no "def b" in the
base class A:

class A:
def a( self ):
return self.b()

class B( A ):
def b( self ):
return "I am a string in B.b."

print( B().a() )

print( A().a() )

. Please look at the following transcript of the execution of this
code:

I am a string in B.b.
AttributeError: 'A' object has no attribute 'b'

. Now, your question should be:

|What makes "b" be a methode of "B()", but not of "A()"?

. And maybe now you can answer it yourself!

On 3/26/23 13:43, Jen Kris wrote:
>
> My question is:  what makes "choose_method" a method of the base class, called as self.choose_method instead of UrnaryConstraint.choose_method?  Is it super(UrnaryConstraint, self).__init__(strength) or just the fact that Constraint is its base class?

When referring to "self" you are referring to an "instance" of the class
or classes, think in terms of objects (the instance, usually self) vs a
blueprint (the class, usually cls).

saying self.choose_method(mark) checks the "instance" of self to see if
it has something called choose_method at run time (instances being
created at run time). If you have an instance of just Constraint, and
never had a choose_method defined for it, you will get an error because
it can't find it (which in this case is presumed as designed). If the
"instance" is of a subclass of Constraint that does have a
choose_method, that also inherits the stuff from Constraint, it will
successfully call it against the "instance" that has been constructed
with attributes of both classes.

if the instance of a subclass has a definition for something that is in
the base class, for instance IF UrnaryConstraint had it's own def
satisfy() method, the instance would call the subclass version. In the
case given, it does not, so it looks to the parent to see if it has
inherited satisfy() from higher up.

Hopefully that helps a little bit.. just have to get a feel for OO
instantiated object vs class..