DEV Community: Richard Vodden

Writing a Geometric Solver in Python - Part 3: Fixing our line

Richard Vodden — Sat, 02 Oct 2021 07:19:43 +0000

So far we have a nice strong framework for expressing geometric constraints as Constraint objects, and we have a clean way of applying these to our geometric objects. We have clear output when we ask the various objects to repr themselves, and we have clear error messages when things don't quite go to plan. Our constraints now support being reciprocal, and if we constraint one object to another that will magically constraint the other object back to the original if we so wish. Where we left it last time is that we needed to update our ConincidentConstraint object so that it implemented this reciprocal feature, and to do that we needed to upgrade our Line object so that it could take constraints. The code from the previous article can be found in this gist.

Upgrading our line.

To get us started in the last article we created a very simple line object:

#... 

class Line:
    def __init__(self, x1, y1, x2, y2):
        self.x1 = x1
        self.y1 = y1
        self.x2 = x2
        self.y2 = y2

    def __repr__(self):
        return f"Line<({self.x1},{self.y1}),({self.x2},{self.y2})>"

Let's look at how we might upgrade that Line to use ConstraintSet so that we can apply constraints to it. How's this for starters:

class Line(ConstraintSet):
    def __init__(self, name="", start=None, end=None):
        super().__init__(name=name)
        self._start = start if start is not None else Point(name + ".start")
        self._end = end if end is not None else Point(name + ".end")

    @property
    def start(self):
        return self._start

    @property
    def end(self):
        return self._end

    def __repr__(self):
        return f"Line({self._name})<{repr(self.start)},{repr(self.end)}>"

l = Line("l")
print(repr(l))

Line(l)<Point(),Point()>

This is great stuff, we have a line which starts at a point and ends at a point. Let's try and play around with it a bit.

l = Line("l")
p = Point(1,2)
l.start = p
print(repr(l))

AttributeError: can't set attribute

Disaster! The issue here is that we didn't define setters for our start and end parameters. But we didn't have to do that when we defined out Point object, so what is going on? Let's revisit that definition of Point:

class Point(ConstraintSet):
    x = ConstrainedValue()
    y = ConstrainedValue()

    def __init__(self, name="", x=None, y=None):
        super().__init__(self)
        self._name = name
        if x is not None:
            self.x = x
        if y is not None :
            self.y = y

    @property
    def name(self):
        return self._name

So we used ConstrainedValue() at the class level when we defined our Point and that looks very neat. Can we do something similar with Line to specify our Point parameters? We could define a ConstrainedPoint object, but this would get very tiresome once we have a large collection of objects. Let's instead modify ConstrainedValue so that it accepts a subclass of ConstraintSet and then use that to specify the parameters of Line:

class ConstrainedValue:
    """An object which can be passed around to represent a value."""

    def __init__(self, constraint_set_class):
        self._constraint_set_class = constraint_set_class
    #... 
    def __get__(self, instance, typ=None):
        # grab the ConstraintSet from the instance
        constraint_set = getattr(instance, self.private_name, None)

        # If the instance didn't have an initialized ConstraintSet then
        # give it one
        if constraint_set is None:
            constraint_set = self._constraint_set_class(name=f"{instance.name}.{self.public_name}")
            setattr(instance, self.private_name, constraint_set)
        return constraint_set
    #... 

class Line(ConstraintSet):
    start = ConstrainedValue(Point)
    end = ConstrainedValue(Point)

    def __init__(self, name="", start=None, end=None):
        super().__init__(name=name)
        if start is not None:
            self.start = start
        if end is not None:
            self.end = end

    def __repr__(self):
        return f"Line({self._name})<{repr(self.start)},{repr(self.end)}>"

And see how it flies:

l = Line("l")
p = Point('p',1,2)
l.start = p
print(repr(l))

AttributeError: 'Line' object has no attribute 'name'

Whoops! Strangely we chose to define the name property on the Point class even though _name is implemented in ConstraintSet. Let's extract that up to ConstraintSet, which will simplify Point a little.

class ConstraintSet:
    #... 
    @property
    def name(self):
        return self._name
    #... 

    def validate_object(self, instance):
        if not isinstance(instance, ConstraintSet):
            raise InvalidConstraintException(f"{self.__class__.__name__} can only"
            f" be applied to `ConstraintSet`, it cannot be applied to `{instance.__class__.__name__}`")

    def apply_reciprocal_constraint(self, instance):
        pass

    def cascade_constraints(self, instance):
        pass
    #... {{% /skip %}}
class Point(ConstraintSet):
    x = ConstrainedValue(ConstraintSet)
    y = ConstrainedValue(ConstraintSet)

    def __init__(self, name="", x=None, y=None):
        super().__init__(self)
        self._name = name
        if x is not None:
            self.x = x
        if y is not None :
            self.y = y

And have another go at defining Line:

class Line(ConstraintSet):
    start = ConstrainedValue(Point)
    end = ConstrainedValue(Point)

    def __init__(self, name="", start=None, end=None):
        super().__init__(name=name)
        if start is not None:
            self.start = start
        if end is not None:
            self.end = end

    def __repr__(self):
        return f"{self.__class__.__name__}({self.name})<{repr(self.start)},{repr(self.end)}>"

l = Line('l')
p = Point('p', 1,2)
l.start = p
print(repr(l))

Line(l)<Point(
    LinkedValueConstraint<p>
),Point()>

Woohoo! This is exactly what we were after.

Returning to the Constraint

So now we must upgrade our CoincidentConstraint so that it provides a reciprocal constraint and implements the three methods with introduced to the Constraint class in the last article. A question we must first answer is what should we call our reciprocal constraint. It seems to me to be equally acceptable to say that a line is coincident with a point as it is to say that a point is coincident with a line. So our natural language tells us that we should use the same constraint object for both the constraint and its reciprocal, which means we need to make our CoincidentConstraint object apply to a Line as well as a Point.

There are other circumstances where this kind of relationship is appropriate. For example if a line is tangent to a circle, then it is equally acceptable to say that the circle is tangent to a line, so it feels like this is a pattern which we may well use again.

Let's remind ourselves what our existing CoincidentConstraint class looks like:

class CoincidentConstraint(Constraint):
    def __init__(self, line):
        self._line = line

    @property
    def line(self):
        return self._line

    def __repr__(self):
        return f"{self.__class__.__name__}<{self.line}>"

    def constraint_callback(self, point):
        if not isinstance(point, Point):
            raise InvalidConstraintException(f"{self.__class__.__name__} can only"
            f" be applied to `Point`, it cannot be applied to `{point.__class__.__name__}`")
        point.x.constrain_with(InfluencedConstraint(self))
        point.y.constrain_with(InfluencedConstraint(self))

Let's first of all add the new methods, without considering the addition of the Line functionality, and we'll leave the apply_reciprocal_constraint method empty for the moment.

class CoincidentConstraint(Constraint):
    #... 

    def validate_object(self, instance):
        if not isinstance(point, Point):
            raise InvalidConstraintException(f"{self.__class__.__name__} can only"
            f" be applied to `Point`, it cannot be applied to `{instance.__class__.__name__}`")

    def apply_reciprocal_constraint(self, instance):
        pass

    def cascade_constraints(self, instance):
        point.x.constrain_with(InfluencedConstraint(self))
        point.y.constrain_with(InfluencedConstraint(self))

We also need to define an __eq__ method to avoid repeating our stack overflow woes from last time, so let's go ahead and do that now.

class CoincidentConstraint(Constraint):
    #... 
    def __eq__(self, other):
        return type(other) == type(self) and self.line == other.line

In order for our CoincidentConstraint to apply to a Line we must allow it to accept a Point. That's a little more messy that it might at first appear, as we'll need to adapt our shiny new __eq__ method to consider this possibility, and the same for our __repr__ method:

class CoincidentConstraint(Constraint):
    def __init__(self, object):
        self._line = object if type(object) == Line else None
        self._point = object if type(object) == Point else None
    #... 
    @property
    def point(self):
        return self._point

    def __repr__(self):
        if self.line is not None:
            return f"{self.__class__.__name__}<{self.line}>"
        return f"{self.__class__.__name__}<{self.point}>"

    #... 
    def __eq__(self, other):
        return type(other) == type(self) and self.line == other.line and self.point == other.point

And now let's modify the validate_object method so that it checks for the correct object type, and tweak cascade_constraints so that it cascades as well to a Line as it does to a Point:

class CoincidentConstraint(Constraint):
    #... 

    def validate_object(self, instance):
        if self._line is not None:
            if not isinstance(instance, Point):
                raise InvalidConstraintException(f"{self.__class__.__name__} which has been"
                " assigned a Line can only be applied to Point, it cannot be applied to"
                f" `{instance.__class__.__name__}`")
        else:
            if not isinstance(instance, Line):
                raise InvalidConstraintException(f"{self.__class__.__name__} which has been"
                " assigned a Point can only be applied to Line, it cannot be applied to"
                f" `{instance.__class__.__name__}`")

    #...

p = Point('p')
c = CoincidentConstraint(p)
l = Line('l')
l.constrain_with(c)
print(repr(l))

Line(l)<Point(
    InfluencedConstraint<CoincidentConstraint<p>>
),Point(
    InfluencedConstraint<CoincidentConstraint<p>>
)>

Aha! Let's alter our Line __repr__ method so that it includes the constraints at the Line level:

class Line(ConstraintSet):
    #... 
    def __repr__(self):
        repr_string = f"{self.__class__.__name__}({self.name})<{repr(self.start)},{repr(self.end)}>"
        if len(self._constraints) == 0:
            return repr_string + "()"
        repr_string += "(\n"
        for constraint in self._constraints:
            repr_string += f"    {constraint}\n"
        repr_string += ")"
        return repr_string

p = Point('p')
c = CoincidentConstraint(p)
l = Line('l')
l.constrain_with(c)
print(repr(l))
m = Line('m')
d = CoincidentConstraint(m)
q = Point('q')
q.constrain_with(d)
print(repr(q))

Line(l)<Point(
    InfluencedConstraint<CoincidentConstraint<p>>
),Point(
    InfluencedConstraint<CoincidentConstraint<p>>
)>(
    CoincidentConstraint<p>
)
Point(
    CoincidentConstraint<m>
)

Now we can see the constraints to which the parameters are bound, as well as those to which the object is bound, or we can for the Line object at least. The Point object is a lot less forthcoming, and on reflection its kind of annoying having to implement __repr__ on every object we define. Is there a way we can do this at the ConstraintSet level and just forget about __repr__ for the rest of time. We can if we make an assumption. I'm pretty sure that the assumption is safe, but I'm also pretty sure that I've been bitten by every other assumption I've ever made. Let's live dangerously and implement a generic __repr__ method. If it bites us we can re-implement it later.

A More Generic Representation

To write something generic, we need a list of the ConstrainedValue attributes in our class. Let's tweak our ConstrainedValue class so that it keeps track:

```python {hl_lines=[4-5,14]}
class ConstrainedValue:
"""An object which can be passed around to represent a value."""
#...
def set_name(self, owner, name):
self.public_name = name
self.private_name = f"_{name}"
# append the name to the list of ConstrainedSets on the class
# creating that list if it doesn't exist
try:
constraint_sets = owner._constraint_sets
except AttributeError:
constraint_sets = []
owner._constraint_sets = constraint_sets
finally:
owner._constraint_sets.append(self.public_name)
#...




Now we can iterate through that list in our `__repr__` method. For the avoidance of doubt, the assumption here being that the only attributes we're printing out are the ones that are participating in our model, and all of those will be of type `ConstraintSet`. Let's see how that goes:

<!--phmdoctest-share-names-->


```python class ConstraintSet: #... 
    def __repr__(self):
        retval = f"{self.name}: {self.__class__.__name__}"
        try:
            num_constraint_sets = len(self._constraint_sets)
        except AttributeError:
            num_constraint_sets = 0
        if num_constraint_sets == 0:
            retval += "()"
        else:
            constraint_set_string = ""
            for constraint_set_name in self._constraint_sets:
                constraint_set_string += repr(getattr(self,constraint_set_name))
            retval += "(\n"
            retval += "    " + "    ".join([l for l in constraint_set_string.splitlines(True)])
            retval += ")\n"

        if len(self._constraints) == 0:
            retval += "<>\n"
        else:
            retval += "<\n"
            for constraint in self._constraints:
                retval += "    " + "    ".join([l for l in repr(constraint).splitlines(True)])
            retval += "\n>\n"
        return retval
    #...

And redefine Point and Line without the __repr__ method:

class Point(ConstraintSet):
    x = ConstrainedValue(ConstraintSet)
    y = ConstrainedValue(ConstraintSet)

    def __init__(self, name="", x=None, y=None):
        super().__init__(self)
        self._name = name
        if x is not None:
            self.x = x
        if y is not None :
            self.y = y

class Line(ConstraintSet):
    start = ConstrainedValue(Point)
    end = ConstrainedValue(Point)

    def __init__(self, name="", start=None, end=None):
        super().__init__(name=name)
        if start is not None:
            self.start = start
        if end is not None:
            self.end = end

#...

These are starting to look super clean! That apparently duplicated code in the __init__ methods hasn't escaped my attention, but I don't want to get distracted. Let's check that that last change worked:

p = Point('p')
c = CoincidentConstraint(p)
l = Line('l')
l.constrain_with(c)
print(repr(l))
m = Line('m')
d = CoincidentConstraint(m)
q = Point('q')
q.constrain_with(d)
print(repr(q))

l: Line(
    l.start: Point(
        l.start.x: ConstraintSet()<>
        l.start.y: ConstraintSet()<>
    )
    <
        InfluencedConstraint<CoincidentConstraint<p>>
    >
    l.end: Point(
        l.end.x: ConstraintSet()<>
        l.end.y: ConstraintSet()<>
    )
    <
        InfluencedConstraint<CoincidentConstraint<p>>
    >
)
<
    CoincidentConstraint<p>
>

q: Point(
    q.x: ConstraintSet()<
        InfluencedConstraint<CoincidentConstraint<m>>
    >
    q.y: ConstraintSet()<
        InfluencedConstraint<CoincidentConstraint<m>>
    >
)
<
    CoincidentConstraint<m>
>

This is a really great output. We can really see how the hierarchy of our constraints is building up. So what about that initializer? Well it turns out we can play a pretty similar trick.

Generic Initialization

Firstly let's describe the behavior we're after, using our Point object as an example:

# Firstly we should be able to define a point specifying nothing at all:
p = Point()

# The it would be great to have a simple constructor which can accept some values:
p = Point(1,2)

# Finally we should be able to specify parameters by nae:
p = Point(x=1, y=2, name='p')

In order to achieve this, in particular the 2nd example, we need to be able to provide a default name. Something like Point1, when no name is specified, but obviously unique for each point created. Let's add a generate_name method to ConstraintSet which can do this for us:

class ConstraintSet:
    #... 
    @classmethod
    def _generate_name(cls):
        try:
            index = cls._counter
        except AttributeError:
            index = 0
        cls._counter = index + 1
        return f"{cls.__name__}{index}"
    #...

It's worth reflecting on how this method works, as its a little subtle. Firstly this method is decorated with @classmethod This means that the class is passed in as the first parameter instead of the instance. By convention this is called cls to distinguish from self in a normal method where the instance is passed in. By using a class method, and the value of cls we can have a different counter for Point and Line. Next try and assign the the value of _counter to index, if we've not yet initialized it this will throw an AttributeError, we catch that and set index to zero. This is an example of "EAFP" or "Easier to ask forgiveness than permission" coding. This rule is not part of PEP20, but it is well established python coding style. Now we set the value of _counter to one more than index, which will initialize counter if its not already, and finally construct our default name out of type(self).__name__ and our index. Let's give it a quick test. The _ prefix by convention means that this is a private method which shouldn't be called from outside of the class, but python does nothing to enforce that, so our test is nice and easy to write:


l = Line()
print(l._generate_name())
print(l._generate_name())
p = Point()
print(p._generate_name())
print(p._generate_name())

Line0
Line1
Point0
Point1

Perfect. Now let's write a generic initializer on ConstraintSet which means we don't have to write initializers on all our objects. Let's remind ourselves of our target behavior:

# Firstly we should be able to define a point specifying nothing at all:
p = Point()

# The it would be great to have a simple constructor which can accept some values:
p = Point(1,2)

# Finally we should be able to specify parameters by nae:
p = Point(x=1, y=2, name='p')

The final behavior is the easiest to implement. We will iterate through the _constraint_sets we built for our __repr__ method and assign values if matching kwargs have been passed. We pop them off kwargs and then pass the remaining kwargs to super().__init__. This last part is important as it preserves our ability to subclass. To pluck an example out of thing air, we might want to create a "DoubleLine" class which draw two lines right next to each other, and takes the distance between the two lines as a parameter:

class DoubleLine(Line):
    distance = ConstrainedValue(ConstraintSet)

dl = DoubleLine(start=Point(1,2), end=Point(2,3), distance=0.1)

If we miss out the "pop and pass" part of our initializer, then Line will never be sent the correct values, and start and end would never be set. A first stab at this generic initializer looks like this:

class ConstraintSet:
    def __init__(self, *args, **kwargs):
        self._constraints = []
        try:
            constraint_sets = self._constraint_sets
        except AttributeError:
            # _constraint_sets is not set if `self` is a top level ConstraintSet
            # so this is not an error, there's just nothing to do.
            pass
        else:
            for constraint_set_name in self._constraint_sets:
                try:
                    setattr(self, constraint_set_name, kwargs.pop(constraint_set_name))
                except KeyError:
                    # Not a problem if a value for _constraint_set_name has not been provided.
                    pass
        super().__init__(*args, **kwargs)

name is not a ConstraintSet so won't appear in our list, so we must explicitly handle that. It's tempting to write something like this:

class ConstraintSet:
    def __init__(self, *args, **kwargs):
        self._constraints = []
        name = kwargs.pop('name') if 'name' in kwargs else self._generate_name
        self._name = name
        # ... ConstraintSet code
    # ...

However if we did write this, then the call to super().__init__() would not have a name parameter, so that call would immediately overwrite our name with a _generate_name value. To prevent this we must check to see if _name is already defined, and only provide a default value if it is not.

class ConstraintSet:
    def __init__(self, *args, **kwargs):
        self._constraints = []
        try:
            if not hasattr(self._name):
                self._name = kwargs.pop('name')
        except IndexError: # 'name' has not been provided as a kwargs, so provide a default value
            self._name = self._generate_name()
        super().__init__(*args, **kwargs)
    #... ConstraintSet code

Lastly we need to consider args. To maximize code reuse, the best thing to do is to work out which ConstraintSet each arg belongs to, and add it explicitly to **kwargs. The initializers are called from the most specific subclass up to the most general. Our DoubleLine for example would have its initializer called first, and then the initializer for Line and finally the initializer for ConstraintSet. We therefore want to start at the end of our list and work towards the start, so that more specific args go at the end of the call. In order to make this work we'll need to split out arg processing into a separate method so that we can call it further up the initializer. Also, by default, args is passed to us a tuple which is immutable, so we'll need to change it to something we can remove values from. A List will do:

    def __init__(self, *args, **kwargs):
        self._constraints = []
        # converts args to a list, so that we can mutate it
        args = list(args)
    #... name code
        kwargs |= self._process_args(args)
    #... ConstraintSet code 

    def _process_args(self, args):
        # give our parent a chance to nab the arguments before us:
        try:
            super().__process_args(args)
        except AttributeError:
            # not a problem if `super() doesn't have `__process_args`
            # just means we're near the top of the tree
            pass

        retval = dict()
        # iterate backwards through our constraints, and add a
        # dictionary entry for each arg whilst one exists
        try:
            for constraint_set_name in self._constraint_sets[::-1]:
                retval[constraint_name] = args.pop()
        except IndexError:
            # just means we got to the end of the list
            pass
        return retval

Putting these together gives us a mammoth initializer, so I've broken out the kwargs processing into a separate method too, to give anyone reading this code half a chance of following it:

class ConstraintSet:

    def __init__(self, *args, **kwargs):
        self._constraints = []
        # convert args to a list, so that we can mutate it
        args = list(args)
        """give ourselves a sensible name unless one is provided."""
        try:
            if not hasattr(self, '_name'):
                self._name = kwargs.pop('name')
        except KeyError: # 'name' has not been provided as a kwargs, so provide a default value
            self._name = self._generate_name()
        """copy args into the appropriate place in kwargs"""
        kwargs |= self._process_args(args)
        """assign each kwarg to its matching ConstraintSet"""
        self._process_kwargs(kwargs)
        super().__init__(*args, **kwargs)

    def _process_args(self, args):
        # give our parent a chance to nab the arguments before us:
        try:
            super().__process_args(args)
        except AttributeError:
            # not a problem if `super() doesn't have `__process_args`
            # just means we're near the top of the tree
            pass

        retval = dict()
        # iterate backwards through our constraints, and add a
        # dictionary entry for each arg whilst one exists
        try:
            for constraint_set_name in self._constraint_sets[::-1]:
                retval[constraint_set_name] = args.pop()
        except (IndexError, AttributeError):
            # just means we got to the end of the list
            pass

        return retval

    def _process_kwargs(self, kwargs):
        try:
            constraint_sets = self._constraint_sets
        except AttributeError:
            # _constraint_sets is not set if `self` is a top level ConstraintSet
            # so this is not an error, there's just nothing to do.
            pass
        else:
            for constraint_set_name in self._constraint_sets:
                try:
                    setattr(self, constraint_set_name, kwargs.pop(constraint_set_name))
                except KeyError:
                    # Not a problem if a value for _constraint_set_name has not been provided.
                    pass

    #... 

    def validate_object(self, instance):
        if not isinstance(instance, ConstraintSet):
            raise InvalidConstraintException(f"{self.__class__.__name__} can only"
            f" be applied to `ConstraintSet`, it cannot be applied to `{instance.__class__.__name__}`")

    def apply_reciprocal_constraint(self, instance):
        pass

    def cascade_constraints(self, instance):
        pass

class ConstrainedValue:
    """An object which can be passed around to represent a value."""

    def __init__(self, constraint_set_class):
        self._constraint_set_class = constraint_set_class

    def __set_name__(self, owner, name):
        self.public_name = name
        self.private_name = f"_{name}"
        # append the name to the list of ConstrainedSets on the class
        # creating that list if it doesn't exist
        try:
            constraint_sets = owner._constraint_sets
        except AttributeError:
            constraint_sets = []
            owner._constraint_sets = constraint_sets
        finally:
            owner._constraint_sets.append(self.public_name)

    def __get__(self, instance, typ=None):
        # grab the ConstraintSet from the instance
        constraint_set = getattr(instance, self.private_name, None)

        # If the instance didn't have an initialized ConstraintSet then
        # give it one
        if constraint_set is None:
            constraint_set = self._constraint_set_class(name=f"{instance.name}.{self.public_name}")
            setattr(instance, self.private_name, constraint_set)
        return constraint_set

    def __set__(self, instance, value):
        # Grab the ConstraintSet from the instance
        constraint_set = self.__get__(instance, None)

        constraint_set.reset_constraints()
        # if the value we've been asked to assign is a ConstraintSet
        # then add a LinkedValueConstraint:
        if isinstance(value, ConstraintSet):
            constraint_set.constrain_with(LinkedValueConstraint(value))
            return

        # otherwise use a FixedValueConstraint to constrain to the provided
        # value
        constraint_set.constrain_with(FixedValueConstraint(value))
    #... {{% /skip %}}

Redefine Point and Line without their initializers...

class Point(ConstraintSet):
    x = ConstrainedValue(ConstraintSet)
    y = ConstrainedValue(ConstraintSet)

class Line(ConstraintSet):
    start = ConstrainedValue(Point)
    end = ConstrainedValue(Point)

#...

Let's test this by revisiting our behaviors:

# Firstly we should be able to define a point specifying nothing at all:
p = Point()
print(repr(p))

# The it would be great to have a simple constructor which can accept some values:
p = Point(1,2)
print(repr(p))

# Finally we should be able to specify parameters by nae:
p = Point(x=1, y=2, name='p')
print(repr(p))

Point0: Point(
    Point0.x: ConstraintSet()<>
    Point0.y: ConstraintSet()<>
)
<>

Point1: Point(
    Point1.x: ConstraintSet()<
        FixedValueConstraint<1>
    >
    Point1.y: ConstraintSet()<
        FixedValueConstraint<2>
    >
)
<>

p: Point(
    p.x: ConstraintSet()<
        FixedValueConstraint<1>
    >
    p.y: ConstraintSet()<
        FixedValueConstraint<2>
    >
)
<>

This is pretty incredible stuff. We've managed to abstract all our functionality into our ConstrainedValue and ConstraintSet classes so that we have this super clean and easy to use developer interface. The only thing which bugs me slightly. Have another look at this listing:

class Point(ConstraintSet):
    x = ConstrainedValue(ConstraintSet)
    y = ConstrainedValue(ConstraintSet)

class Line(ConstraintSet):
    start = ConstrainedValue(Point)
    end = ConstrainedValue(Point)

To my mind, ConstrainedValue(Point) is intuitive. It clearly says that we'd like a constrained value and that it should be of type Point. ConstrainedValue(ConstraintSet) doesn't have the same feel however, it really isn't clear what type the value is. Let's fix that by adding an alias clas to ConstrainedSet which has a more appropriate name for the end user:

class Scalar(ConstraintSet):
    """Alias for ConstraintSet to provide more intuitive name"""
    pass

class Point(ConstraintSet):
    x = ConstrainedValue(Scalar)
    y = ConstrainedValue(Scalar)

#... 
p = Point(1,2)
print(repr(p))

Point0: Point(
    Point0.x: Scalar()<
        FixedValueConstraint<1>
    >
    Point0.y: Scalar()<
        FixedValueConstraint<2>
    >
)
<>

Let's just quickly check that we've not broken anything:

#... 
p = Point()
c = CoincidentConstraint(p)
l = Line()
l.constrain_with(c)
q = Point()
l.start = q
print(repr(l))

Line0: Line(
    Line0.start: Point(
        Line0.start.x: Scalar()<>
        Line0.start.y: Scalar()<>
    )
    <
        LinkedValueConstraint<Point1>
    >
    Line0.end: Point(
        Line0.end.x: Scalar()<>
        Line0.end.y: Scalar()<>
    )
    <
        InfluencedConstraint<CoincidentConstraint<Point0>>
    >
)
<
    CoincidentConstraint<Point0>
>

Small bug, looks like the LinkedValueConstraint has nuked the InfluencedConstraint from Line0.end. This is because our __set__ method in ConstrainedValue calls reset_constraints which probably seemed like a good idea at the time, but now looks more like a bug. Let's remove that call:

class ConstrainedValue:
    """An object which can be passed around to represent a value."""
    #... 
    def __set__(self, instance, value):
        # Grab the ConstraintSet from the instance
        constraint_set = self.__get__(instance, None)

        # if the value we've been asked to assign is a ConstraintSet
        # then add a LinkedValueConstraint:
        if isinstance(value, ConstraintSet):
            constraint_set.constrain_with(LinkedValueConstraint(value))
            return

        # otherwise use a FixedValueConstraint to constrain to the provided
        # value
        constraint_set.constrain_with(FixedValueConstraint(value))

#...

#... 
p = Point()
c = CoincidentConstraint(p)
l = Line()
l.constrain_with(c)
q = Point()
l.start = q
print(repr(l))

Line0: Line(
    Line0.start: Point(
        Line0.start.x: Scalar()<>
        Line0.start.y: Scalar()<>
    )
    <
        InfluencedConstraint<CoincidentConstraint<Point0>>
        LinkedValueConstraint<Point1>
    >
    Line0.end: Point(
        Line0.end.x: Scalar()<>
        Line0.end.y: Scalar()<>
    )
    <
        InfluencedConstraint<CoincidentConstraint<Point0>>
    >
)
<
    CoincidentConstraint<Point0>
>

Phew! We made it! We now have a super powerful little framework with which we can model constraints. It's really worth reflecting on what we've achieved here. Not only have we implemented all that power, but if we compare the implementation of our Point with the naive implementation we started with at the beginning of part 1, you'll see its actually simpler to implement using our framework than without.

In the next article we'll look at adding some more constraints into the mix. In particular we'll look at how we can do some simple arithmetic operations with out ConstraintSet.

Writing a Geometric Solver in Python - Part 2: More Modelling

Richard Vodden — Mon, 20 Sep 2021 07:15:28 +0000

This is the second article in a short series about adding a geometric solver for my PySketcher side project. The basic premise is that instead of having to tell PySketcher exactly where you'd like your shapes to be, you'll be able to specify the relationships the shapes have to each other, and PySketcher will be able to work our where they need to go. Have a read of Part 1 for more details, and for an explanation of how we've built up the model so far.

Recapitulation

We've built a model, which consists of a ConstrainedValue class. This class is a Descriptor and is assigned to classes. When ConstrainedValue is used in a class, that class will store ConstraintSet objects instead of raw values. This means that we can use the constrain_with method of ConstraintSet to indicate that the value of that ConstraintSet is in some way constrained. We built a trivial constraint FixedValueConstraint which indicates that the value ofa ConstraintSet is constrained to, unsurprisingly, a fixed value. We also built aLinkedValueConstraint which indicates that a ConstraintSet is constrained to the value of another ConstraintSet. We implemented a throwaway resolve method on ConstraintSet so that we can test how our model hangs together. Finally we spent some time ensuring that the experience was intuitive for people using the model, and that it was possible to interrogate the model to see how things are stitched together. Whilst we were considering the concepts above we implemented a smallPoint object and used that, with our throwaway revolve method, to illustrate that our modelling code is effective. The full code is available in this gist, and this is an example of it in use:

#... 
class Point:
    x = ConstrainedValue()
    y = ConstrainedValue()

    def __init__(self, name="", x=None, y=None):
        self._name = name
        if x is not None:
            self.x = x
        if y is not None :
            self.y = y

    @property
    def name(self):
        return self._name

p = Point('p', 1,2)
q = Point('q')
print(f"p.x is {p.x}")
print(f"p.x resolves to {p.x.resolve()}")
q.x = p.x
print(f"q.x is {repr(q.x)}")
print(f"q.x resolves to {q.x.resolve()}")
p.x = 2
print(f"Now p.x has changed, q.x resolves to {q.x.resolve()}")

p.x is p.x
p.x resolves to 1
q.x is ConstraintSet(
    LinkedValueConstraint<p.x>
)
q.x resolves to 1
Now p.x has changed, q.x resolves to 2

Top line stuff. We can define an object with some parameters and constrain those parameters using neat little constraints which are tiny standalone objects in themselves.

Drawing a line under it

Next, we'd like to be able to represent more complex relationships. We may, for example, wish to constrain our point to being on a line, or perhaps on the circumference of a circle. In both of these examples the value of xis only known if the value of y is known and visa versa; yet neither can take arbitrary values.Before we consider how we might do that, let's build a simple line object. For the moment we won't worry about using ConstrainedValue in this line, as we wish to constrain the point to the line. We can revisit the Line object later on when we've established some patterns.

class Line:
    def __init__(self, x1, y1, x2, y2):
        self.x1 = x1
        self.y1 = y1
        self.x2 = x2
        self.y2 = y2

    def __repr__(self):
        return f"Line<({self.x1},{self.y1}),({self.x2},{self.y2})>"

l = Line(0,1,2,3)
print(l)

Line<(0,1),(2,3)>

As you can see, we've kept this super simple, and haven't even defined properties for x1, x2etc. It should serve our needs for the moment. Now how might we indicate that our Point is constrained to this line? The answer is surprisingly simple. The Point needs to be able to accept a constraint, and the easiest way to do that is to have it inherit from ConstraintSet:

class Point(ConstraintSet):
    x = ConstrainedValue()
    y = ConstrainedValue()

    def __init__(self, name="", x=None, y=None):
        super().__init__(self)
        self._name = name
        if x is not None:
            self.x = x
        if y is not None :
            self.y = y

    @property
    def name(self):
        return self._name

Here the only changes are the first line of the class, which specifies ConstraintSet as a superclass, and the first line of __init__ which adds the call to the superclass initializer. As we've now inherited from ConstraintSet, our Point class has a constrain_with method which can use to supply a Constraint which indicates that our point should be constrained to a Line. The fancy pants maths people say that if a point is on a line, then it "coincident", so let's use their fancy pants language and define a CoincidentConstraint:

class CoincidentConstraint(Constraint):
    def __init__(self, line):
        self._line = line

    @property
    def line(self):
        return self._line

    def __repr__(self):
        return f"{self.__class__.__name__}<{self.line}>"

l = Line(1,2,3,4)
p = Point('p')
p.constrain_with(CoincidentConstraint(l))
print(repr(p))

ConstraintSet(
    CoincidentConstraint<Line<(1,2),(3,4)>>
)

Crisis of identity

Well our point is now telling us that it's constrained, and is listing out the constraints correctly, but it seems to be having a bit of an identity crisis. It's telling us that it's aConstraintSet, and whilst that is true to a certain extent, it should really tell us that it is aPoint. The issue is because when we originally wrote the __repr__ method in ConstraintSet we hardcoded the class name (tsk). Let's address that:

class ConstraintSet:
#... 

    def __repr__(self):
        retval = f"{self.__class__.__name__}("
        if len(self._constraints) == 0:
            retval += ")"
            return retval

        for constraint in self._constraints:
            retval += f"\n    {constraint}"
        retval += "\n)"
        return retval

#... 

l = Line(1,2,3,4)
p = Point('p')
p.constrain_with(CoincidentConstraint(l))
print(repr(p))

Point(
    CoincidentConstraint<Line<(1,2),(3,4)>>
)

Excellent! Our Point is a Point again, and its correctly reporting its constraints.

Cascading Constraints

What happens if we look at the co-ordinates of the Point?

l = Line(1,2,3,4)
p = Point('p')
p.constrain_with(CoincidentConstraint(l))
print(repr(p.x))

ConstraintSet()

That's not so good. Whilst it is true that we have not directly constrained the x coordinate, it is not true that the x coordinate is not constrained. It would be much better if the xcoordinate could tell us that it was being constrained by the CoincidentConstraint at the Point level.We could just have the constrain_with method apply the CoincidentConstraint to the x and ycoordinates, and this is certainly a valid approach.

However, let's think more broadly than our current scenario for a moment. We may, for example, be constraining a line to be horizontal. A line (or at least our line) is defined by two points, which in turn are each defined by two values, their x and y co-ordinates. Constraining a line to being horizontal is only constraining the y co-ordinates of those two point (constraining them to being equal) and there is no way that our constrain_with method can know this. If we were to just apply the HorizontalConstraint to all the properties then we'd end up with the x co-ordinates showing the that they were constrained, which is misleading.

So we need an alternative approach. It is only really our Constraint implementations which will understand which properties need to be constrained. So we need a mechanism for the constrain_withmethod to give the constraint the means to, in turn, constrain the properties of the object it is constraining. To achieve this we'll use a design pattern called a "callback". We'll define a constrain_callback method on the Constraint which accepts a ConstraintSet object.Then we will update our constrain_with method to call that constrain_callback method. Theconstrain_callback method can then be overridden by the various implementations of Constraint to apply the necessary downstream constraints.

So step 1, we need to modify our Constraint definition to include a constraint_callback method.We face a design decision at this point. We can either declare this method to be an@abstractmethod which will force implementations of Constraint to implement it, or we can provide a default implementation, which will do nothing, meaning that our implementations can just pretend the constraint_callback doesn't exist if they don't wish to constrain properties. It's not particularly clear which direction we should go here. If we provide a default implementation then we risk our users forgetting that it needs to be implemented, and therefore some nasty bugs. If we don't then implementations will have to explicitly state that they want the constraint_callback to do nothing. This is simply a question of style, neither option is particularly better than the other. For pythonic questions of style we should always refer to PEP20 - the zen of python and yet again, in this case, it does not let us down. Rule 2 is "Explicit is better than implicit." so rather than providing a default implementation which implicitly does nothing, we will require our implementations to provide an explicit implementation of the method which does nothing (if that's what they require). In practice this means that we will decorate our method with @abstractmethod:

from abc import ABC, abstractmethod

class Constraint(ABC):
    """Used to restrict that value of a `ConstrainedValue`."""

    @abstractmethod
    def constraint_callback(self, instance):
        raise NotImplementedError("`constraint_callback` must be implemented explicitly.")

And as a direct result of our design decision we need to update our constraints to include a definition of that method. In the case of FixedValueConstraint and LinkedValueConstraint it can simply do nothing. CoincidentConstraint is a touch more complicated so we'll look at that a little later.

class FixedValueConstraint(Constraint):
#... 
    def constraint_callback(self, instance):
        pass

class LinkedValueConstraint(Constraint):
#... 
    def constraint_callback(self, instance):
        pass

Step two is to update our constrain_with method to call the callback:

class ConstraintSet:
#... 

    def constrain_with(self, constraint):
        constraint.constraint_callback(self)
        """Add a constraint to this objects list of constraints."""
        self._constraints.append(constraint)

#...

Now we need to decide how we're going to actually constrain the parameters. One approach could be to apply the CoincidentConstraint to the x and y. I've thought about this, and I can't see a reason why it technically wouldn't work, however it does create an ambiguity. It would not be clear if the CoincidentConstraint had been applied directly to the x or if it had inherited it from its parent shape. So to avoid this we're going to create an InfluencedConstraint. This new constraint will indicate that the parameter is constrained by something higher up the food chain.

class InfluencedConstraint(Constraint):
    def __init__(self, constraint):
        self._constraint = constraint

    def constraint_callback(self, instance):
        pass

    @property
    def constraint(self):
        return self._constraint

    def __repr__(self):
        return f"{self.__class__.__name__}<{self.constraint}>"

Now we're ready to implement the callback_constraint method on the CoincidentConstraint to have it indicate that it is influencing the two co-ordinates.

class CoincidentConstraint(Constraint):
#... 

    def constraint_callback(self, point):
        point.x.constrain_with(InfluencedConstraint(self))
        point.y.constrain_with(InfluencedConstraint(self))

Let's take this for a spin and see how it goes!

l = Line(1,2,3,4)
p = Point('p')
p.constrain_with(CoincidentConstraint(l))
print(f"p is {repr(p)}")
print(f"p.x is {repr(p.x)}")

p is Point(
    CoincidentConstraint<Line<(1,2),(3,4)>>
)
p.x is ConstraintSet(
    InfluencedConstraint<CoincidentConstraint<Line<(1,2),(3,4)>>>
)

That looks ideal. The Point object is expressing that it is constrained by theCoincidentConstraint and if we look at the x coordinate we can see that it is influenced by theCoincidentConstraint and even see exactly which line the CoincidentConstraint is constraining to. This might get a bit verbose in complex diagrams, but right now its perfect for our needs, so let's leave it like that and worry about verbosity if and when it becomes an issue.

What type of fool do you take me for?

Let's try something a little off the wall. Let's try constraining p.x with aCoincidentConstraint. As CoincidentConstraint is only designed to apply to Point objects, it's likely to do something a little strange when applied to a ConstraintSet:

l = Line(1,2,3,4)
p = Point('p')
p.x.constrain_with(CoincidentConstraint(l))
print(repr(p.x))

AttributeError: 'ConstraintSet' object has no attribute 'x'

Oh dear! This isn't a very helpful error message is it? Whilst in our simple example its probably easy enough to work out what has gone on, more complex scenarios could lead to some real head scratching. To resolve this, let's have the constraint_callback check that the constraint is being applied to a sensible object. In this case it only really makes sense forCoincidentConstraint to be applied to a Point, so let's enforce that. And let's create a customRuntimeError object with a nice error message to tell our users what is going on.


class InvalidConstraintException(RuntimeError):
    """Indicates that a constraint has been applied to an object which doesn't make sense."""

class CoincidentConstraint(Constraint):
#... 

    def constraint_callback(self, point):
        if not isinstance(point, Point):
            raise InvalidConstraintException(f"{self.__class__.__name__} can only"
            f" be applied to `Point`, it cannot be applied to `{point.__class__.__name__}`")
        point.x.constrain_with(InfluencedConstraint(self))
        point.y.constrain_with(InfluencedConstraint(self))

Let's see how that's improved things:

l = Line(1,2,3,4)
p = Point('p')
p.x.constrain_with(CoincidentConstraint(l))
print(repr(p.x))

InvalidConstraintException: CoincidentConstraint can only be applied to `Point`, it cannot be applied to `ConstraintSet`.

This is much better, and likely to save our developers a chunk of time as compared with the old"missing attribute" error message. Spoiler alert though, this specific implementation will come back to bite us in the next section. Comment if you can see why, and no cheating by reading the next section first!

One way or another.

Let's take stock of where we have got to. We have a nice strong framework for expressing geometric constraints as Constraint objects, and we have a clean way of applying these to our geometric objects. We have clear output when we ask the various objects to repr themselves, and we have clear error messages when things don't quite go to plan. There are just a couple of corners we need to clear up before we can call ourselves done. Look at the following example:

p = Point('p')
q = Point('q')

q.x = p.x
print(f"p.x is {repr(p.x)}")
print(f"q.x is {repr(q.x)}")

p.x is ConstraintSet()
q.x is ConstraintSet(
    LinkedValueConstraint<p.x>
)

This is a tremendously powerful thing to be able to do. We can create a point and say nothing about it, then refer to it in constraints. What would happen, though, if we were solving our constraint system (the subject of a later article) and q was given a value first? Equality is a reciprocal condition, and when we assert that q.x = p.x we are equally saying that p.x = q.x.We could force this on our users. We could decide that for the purposes of our geometric solver,such operations are not reciprocal, and that users must specify both sides of the relationship:

p = Point('p')
q = Point('q')

q.x = p.x
p.x = q.x
print(f"p.x is {repr(p.x)}")
print(f"q.x is {repr(q.x)}")

p.x is ConstraintSet(
    LinkedValueConstraint<q.x>
)
q.x is ConstraintSet(
    LinkedValueConstraint<p.x>
)

Whilst this does tick the PEP20 "explicit is better than implicit" rule, rule three of the same says"Simple is better than complex". I'm reasonably sure that every geometric relationship is in someway reciprocal. If l is parallel to m then m is parallel to l. Even with ourCoincidentConstraint if our point is on the line, then our line must go through the point. Let's update our LinkedValueConstraint to apply the reciprocal constraint.

class LinkedValueConstraint(Constraint):
#... 
    def constraint_callback(self, instance):
        if not isinstance(instance, ConstraintSet):
            raise InvalidConstraintException(f"{self.__class__.__name__} can only"
            f" be applied to `ConstraintSet`, it cannot be applied to `{point.__class__.__name__}`")
        self.constraint_set.constrain_with(LinkedValueConstraint(instance))
        pass

And let's try again:

p = Point('p')
q = Point('q')

q.x = p.x
print(f"p.x is {repr(p.x)}")
print(f"q.x is {repr(q.x)}")

RecursionError: maximum recursion depth exceeded while calling a Python object

Oops! What's going on here? Well the problem is that the LinkedValueConstraint applies a reciprocal constraint by enforcing a LinkedValueConstraint on the original ConstraintSet which in turn tries to apply a reciprocal constraint etc. And the whole world explodes in a glorious stack overflow (first one of the project though, I'm proud!). We could fix this by adding some kind of flag to constrain_with and constraint_callback to indicate that this is a reciprocal call and that they should not apply the reciprocal constraint as its already done. This is crying out to be forgotten and to lead to some nasty stack overflow type bugs. I think a neater solution is to haveconstrain_with check to see if an identical constraint has already been applied and just exit cleanly if it has. To do this we need to establish what it means for two LinkedValueConstraints to be equal:

class LinkedValueConstraint(Constraint):
#... 
    def __eq__(self, other):
        return isinstance(other, self.__class__) and self.constraint_set == other.constraint_set

Here we've said that a LinkedValueConstraint is only equal to another object, if and only if that other object is also a LinkedValueConstraint and they are both linked to the same ConstraintSet.

p = Point()
l = LinkedValueConstraint(p.x)
m = LinkedValueConstraint(p.x)
n = LinkedValueConstraint(q.x)
print(f"l == m: {l == m}")
print(f"l == n: {l == n}")

l == m: True
l == n: False

And let's stitch this into our constrain_with method:

class ConstraintSet:
#... 

    def constrain_with(self, constraint):
        if constraint in self._constraints:
            return
        constraint.constraint_callback(self)
        """Add a constraint to this objects list of constraints."""
        self._constraints.append(constraint)

#...

Let's see if that solved our stack overflow:

p = Point('p')
q = Point('q')

q.x = p.x
print(f"p.x is {repr(p.x)}")
print(f"q.x is {repr(q.x)}")

RecursionError: maximum recursion depth exceeded

It didn't! Nightmare! The issue here is that we are using the constraint_callback to apply the reciprocal constraint, but that is being called before the constraint is added toself._constraints in the Constraint class. We need it to be that way around because theconstraint_callback is also validating that the object is of a suitable type. Aha! This is our issue. Every time we have to use the work "also" to describe what an object or method is doing, then we likely have ourselves a separation of concerns issue. This was the mistake which I gave you the spoiler alert for earlier! Let's split our constraint_callback into three: a validate_object method, an apply_reciprocal_constraint method, and finally thecascade_constraints.

from abc import ABC, abstractmethod

class Constraint(ABC):
    """Used to restrict that value of a ```

ConstrainedValue

```."""

    @abstractmethod
    def validate_object(self, instance):
        """Validates that `instance` is suitable. Raises `InvalidConstraintException` if not"""
        raise NotImplementedError("`validate_object` must be implemented explicitly.")

    @abstractmethod
    def apply_reciprocal_constraint(self, instance):
        """Applies a matching constraint to the provided instance."""
        raise NotImplementedError("`apply_reciprocal_callback` must be implemented explicitly.")

    @abstractmethod
    def cascade_constraints(self, instance):
        """Applies appropriate constraints to the properties of `instance`."""
        raise NotImplementedError("`cascade_constraints` must be implemented explicitly.")

And let's update our LinkedValueConstraint:

class LinkedValueConstraint(Constraint):
#... 
    def validate_object(self, instance):
        if not isinstance(instance, ConstraintSet):
            raise InvalidConstraintException(f"{self.__class__.__name__} can only"
            f" be applied to `ConstraintSet`, it cannot be applied to `{point.__class__.__name__}`")

    def apply_reciprocal_constraint(self, instance):
        self.constraint_set.constrain_with(LinkedValueConstraint(instance))

    def cascade_constraints(self, instance):
        pass
#...

And finally sort out ConstraintSet:

class ConstraintSet:
#... 

    def constrain_with(self, constraint):
        constraint.validate_object(self)
        if constraint in self._constraints:
            return
        """Add a constraint to this objects list of constraints."""
        self._constraints.append(constraint)
        constraint.cascade_constraints(self)
        constraint.apply_reciprocal_constraint(self)

#...

This has had the happy effect of making the constrain_with method much more readable. Let's see if its finally resolved our stack overflow.

p = Point('p')
q = Point('q')

q.x = p.x
print(f"p.x is {repr(p.x)}")
print(f"q.x is {repr(q.x)}")

p.x is ConstraintSet(
    LinkedValueConstraint<q.x>
)
q.x is ConstraintSet(
    LinkedValueConstraint<p.x>
)

Hooray! That was a surprising amount of work for the apparently simple task of implementing reciprocal relationships!

Wrapping it all up

As a final flourish we need to update our existing constraints to have these new methods. OurFixedValueConstraint is trivial, we shall just implement each as a no-op:

class FixedValueConstraint(Constraint):
#... 
    def validate_object(self, instance):
        pass

    def apply_reciprocal_constraint(self, instance):
        pass

    def cascade_constraints(self, instance):
        pass

InfluencedConstraint at first feels like it might be a little more complex. Validation is straightforward, it can only apply to another ConstraintSet object, or child object. But what about the reciprocal constraint? In fact, we don't need to do anything here, as the reciprocal object is the "higher up one". If, for example, InfluencedConstraint is being applied to p.x, that's becauseCoincidentConstraint has been applied to p so we already know that the reciprocal constraint isin place, as such we don't need to do anything. Similarly we can make no assumptions as to what constraints will need to be cascaded and we'll leave that to the "higher up" object should that be necessary:

class InfluencedConstraint(Constraint):
    #... 

    def validate_object(self, instance):
        if not isinstance(instance, ConstraintSet):
            raise InvalidConstraintException(f"{self.__class__.__name__} can only"
            f" be applied to `ConstraintSet`, it cannot be applied to `{point.__class__.__name__}`")

    def apply_reciprocal_constraint(self, instance):
        pass

    def cascade_constraints(self, instance):
        pass

We've already done LinkedValueConstraint so that only leaves CoincidentConstraint. In order todo that we'll need to upgrade our Line object to be able to take constraints, and as this article is already about twice as long as I intended, let's leave that for next time! In the next article we'll look at upgrading our Line to be able to accept Constraint objects, and in so doing we'll walk a path towards some pretty powerful generics.

Let's Git ready to rumble

Richard Vodden — Thu, 16 Sep 2021 12:23:14 +0000

Solving it

If found myself with a rather strange git problem. As far as I was aware,
I was tracking a remote, however when ever I git a git pull, my bash
prompt would show me as having commits outstanding.

[voddenr:~/repository] master(4)+i ±

Looking at the commit tree, it would seem that origin/HEAD and
origin/master have not been correctly updated:

*   f786359 - (HEAD -> master) Merge everything together. (3 hours ago) <Richard Vodden>
|
*   51955ca - Wrote some code. (4 hours ago) <Richard Vodden>
|\
| |
| * 81e4c19 - Update readme. (4 hours ago) <Richard Vodden>
| |
| * a84e10e - wip (15 hours ago) <Richard Vodden>
|/
|
*   2dcce03 - (origin/master, origin/HEAD) Some kind of merge message. (24 hours ago) <Richard Vodden>
|\
| |
| * f1622f9 - This is quite a boring message. (24 hours ago) <Richard Vodden>
| |
| * 2bbc060 - Even more exciting message. (25 hours ago) <Richard Vodden>
| |
| * 19756aa - Exciting commit message (25 hours ago) <Richard Vodden>

Executing git remote -vv show origin suggests all is as it should be:

* remote origin
  Fetch URL: https://github.com/paulgibbs/behat-wordpress-extension
  Push  URL: https://github.com/paulgibbs/behat-wordpress-extension
  HEAD branch: master
  Local branches configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push': 
    master pushes to master (up to date)

However git branch -a -vv show's something amiss:

git remote -a -v -v shows:

* master                           ef786359 Merge everything together
  remotes/origin/HEAD              -> origin/master

This should show [origin/master] after the commit hash - which it
clearly doesn't. So whilst my master branch is set to push and pull to the
right places, its not correctly set to track origin/master. However when
I attempt to execute git branch --set-upstream-to origin master to fix
that, Git replies with fatal: Cannot setup tracking information; starting point 'origin/master' is not a branch.

A quick google of that error message reveals
this stackoverflow
answer.
It would seem that git remote set-branches --add origin master is the answer here. After
executing it, git remote -a -v -v shows things are as they should be:

* master                 eef78635 [origin/master] Merge everything together
  remotes/origin/HEAD    -> origin/master

Similarly, git remote -vv show origin is looking better. A distinct
learning point for me is that it now reports that it's tracking - see
lines 5 and 6.

* remote origin
  Fetch URL: https://github.com/paulgibbs/behat-wordpress-extension
  Push  URL: https://github.com/paulgibbs/behat-wordpress-extension
  HEAD branch: master
  Remote branch:
    master tracked
  Local branches configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push': master pushes to master (up to
  date)

Following a sneaky git pull everything in the tree is as it should be.
The pointers are all at the latest commit:

*   f786359 - (HEAD -> master, origin/master, origin/HEAD) Merge everything together. (3 hours ago) <Richard Vodden>
|
*   51955ca - Wrote some code. (4 hours ago) <Richard Vodden>
|\
| |
| * 81e4c19 - Update readme. (4 hours ago) <Richard Vodden>
| |
| * a84e10e - wip (15 hours ago) <Richard Vodden>
|/
|
*   2dcce03 - Some kind of merge message. (24 hours ago) <Richard Vodden>
|\
| |
| * f1622f9 - This is quite a boring message. (24 hours ago) <Richard Vodden>
| |
| * 2bbc060 - Even more exciting message. (25 hours ago) <Richard Vodden>
| |
| * 19756aa - Exciting commit message (25 hours ago) <Richard Vodden>

Recreating it.

I believe that I don't truly understand a problem unless I can re-create
it. My first attempt was to delete my local remote tracking branch with
git branch -d -r origin/master. This, however,
showed a much more easily diagnosed output from git branch -a -vv:

* master                 eef78635 [origin/master: gone] Merge everything together

Similarly git remote -vv show origin implies that all will fix itself
from here following a simple git pull:

* remote origin
  Fetch URL: https://github.com/paulgibbs/behat-wordpress-extension
  Push  URL: https://github.com/paulgibbs/behat-wordpress-extension
  HEAD branch: master
  Remote branch:
    master new (next fetch will store in remotes/origin)
  Local branches configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

Next I tried git remote set-branches origin dev dev being another
brand I picked more or less at random from the remote. This looked a good
deal more promising, with git remote -vv show origin showing:

* remote origin
  Fetch URL: https://github.com/paulgibbs/behat-wordpress-extension
  Push  URL: https://github.com/paulgibbs/behat-wordpress-extension
  HEAD branch: master
  Remote branch:
    refs/remotes/origin/dev stale (use 'git remote prune' to remove)
  Local branches configured for 'git pull':
    dev    merges with remote dev
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

No luck, however, as when I inspect with git show-ref I can see that
origin/master no longer exists. So right now I'm stuck. If anyone has
any suggestions as to how to re-create the issue I came across - please do
share in the comments below.

MathJax and Hugo

Richard Vodden — Thu, 16 Sep 2021 11:40:14 +0000

The is a marvelous article which explains how to use Hugo and MathJax in close harmony. Unfortunately it was written a while ago and only works for MathJax 2.x. This article updates the content of the original to MathJax > 3.1. The original is still worth reading as it nicely explains the functionality.

Firstly MathJax > 3.0 likes to have pollyfill. So the script inclusion should look like this:

<script src="https://polyfill.io/v3/polyfill.min.js?features=es6"></script>
<script id="MathJax-script" async src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"></script>

The solution to the problem of having to escape many characters in LaTeX markup is solved in a simlar manner, however a combination of Hugo now using the Goldmark renderer and the MathJax API changing quite significantly at version 3.0, it largely needs re-writing. Firstly the script to add the class to the code blocks now looks like this:

<script>
  window.MathJax = {
    tex: {
      inlineMath: [['{% katex inline %}','{% endkatex %}'], ['\\(','\\)']],
      displayMath: [['{% katex inline %}{% endkatex %}','{% katex inline %}{% endkatex %}'], ['\[','\]']],
      processEscapes: true,
      processEnvironments: true
    },
    options: {
      skipHtmlTags: ['script', 'noscript', 'style', 'textarea', 'pre']
    },
    startup: {
      pageReady() {
        return MathJax.startup.defaultPageReady().then(function () {
          var all = window.MathJax.startup.document.getMathItemsWithin(document.body), i;
          for(i = 0; i < all.length; i += 1) {
            console.log(all[i])
            all[i].start.node.parentNode.className += ' has-jax';
          }
        });
      }
    }
  };
  </script>

Now, by default, the Goldmark renderer does not permit raw html in markdown, instead converting it to a comment. To change this behaviour the Hugo configuration needs the following code added:

[markup]
  [markup.goldmark]
    [markup.goldmark.renderer]
      unsafe = true

Now, LaTeX can be included in <div> tags without worrying about having to escape either _ or \ characters. The following code:

<div>
{% katex inline %}{% endkatex %}
\begin{align*}
  \phi(x,y) &= \phi \left(\sum_{i=1}^n x_ie_i, \sum_{j=1}^n y_je_j \right) \\
  &= \sum_{i=1}^n \sum_{j=1}^n x_i y_j \phi(e_i, e_j) \\
  &= (x_1, \ldots, x_n) \left( \begin{array}{ccc}
      \phi(e_1, e_1) & \cdots & \phi(e_1, e_n) \\
      \vdots & \ddots & \vdots \\
      \phi(e_n, e_1) & \cdots & \phi(e_n, e_n)
    \end{array} \right)
  \left( \begin{array}{c}
      y_1 \\
      \vdots \\
      y_n
    \end{array} \right)
\end{align*}
{% katex inline %}{% endkatex %}
</div>

renders as:

\begin{align*}
\phi(x,y) &= \phi \left(\sum_{i=1}^n x_ie_i, \sum_{j=1}^n y_je_j \right) \
&= \sum_{i=1}^n \sum_{j=1}^n x_i y_j \phi(e_i, e_j) \
&= (x_1, \ldots, x_n) \left( \begin{array}{ccc}
\phi(e_1, e_1) & \cdots & \phi(e_1, e_n) \
\vdots & \ddots & \vdots \
\phi(e_n, e_1) & \cdots & \phi(e_n, e_n)
\end{array} \right)
\left( \begin{array}{c}
y_1 \
\vdots \
y_n
\end{array} \right)
\end{align*}

Writing a Geometric Solver in Python - Part 1: Modelling Constraints

Richard Vodden — Mon, 13 Sep 2021 07:21:20 +0000

PySketcher is little library that I maintain. It makes it simple to draw geometric images. Originally written by Hans Petter Langtangen, who sadly passed away in 2016, and I've been keeping it up to date and adding features since 2019.

Right now, PySketcher only supports absolute positioning of shapes. This means that you have to know exactly where you'd like the center of your circle to be and exactly what radius it should have.

I'd like to add a facility for a user to describe the various geometric features and relationships which the shapes have, as well as potentially being able to specify the properties absolutely. So instead of saying "I'd like to have a circle of radius $3$ and centered at the point $(0, 0)$ , a user could say "Please create me a circle which is centered where these two lines cross and is tangent to this other line."

This presents some interesting challenges:

How will the relationships between the shapes be represented.
Once the relationships are understood, how will we work out where the shapes should go? Can we do this without creating performance issues?
What should the experience be for the developer coding a diagram when they want to represent relationships in code?

At first glance it may look like the first and last items are the same. In fact, the representation and the developer experience are separate concerns. For example if I wish to specify that two lines are parallel, I am constraining the gradient of the 2^nd line to be the same as the first. I don't think there is any argument that the concept of "parallel" is more intuitive, however a gradient equality constraint may make more sense from an implementation perspective.

So over a series of articles, I shall explore each of these challenges. This will hopefully be interesting to some readers, and will also help document my thought processes. That way when in two years I look at my code and think "Why on earth did you to that?" I may have some way of understanding my original justification.

The Problem

In this article let's focus on the problem of how to represent the relationships between shapes internally to PySketcher. This is probably a little backwards, as we'd usually like to consider how the users (or developers in this instance) interact with the library before we look at the internals, but in this instance looking at the internals gives us a quite valuable insight into the art of the possible. And we won't completely ignore the developers - we'll look at the internals whilst considering what potential options that opens up for our API in part 3.

So we'd like for PySketcher to enable us to specify a number of shapes, and for us to then specify how those shapes interact, and for this to be represented somehow internally. We'll leave the problem of working out what the shapes end up looking like to part 2. I think it's useful to think about what we're actually saying when we specify a relationship, and I return to the example of parallelization which I briefly mentioned earlier. If we say that a line is parallel to another line, then we are restricting the values which its gradient can take. This means that we may not know what the gradient of the line is when we create it, but instead we'll need to allow it to be worked out later. Perhaps more subtle is to realise that we may not know what the gradient is when we assign that constraint. If we assert that one line is parallel to another, but don't yet know the gradient of that other line (as we've not yet asserted all the constraints in the diagram), then we will be unable to assign the value of the gradient at assignment time. So we need a means to:

Represent that a shape has some property or value without knowing what that value might be (yet).
Be able to assign constraints to that property or value.
Trigger the calculation of the value on the basis of the constraints.

Constrained Thinking

Let's have a look at how we might implement this. As with all my python articles, where you see a line which says #... that means I've omitted some code for clarity, and usually that code is code from a previous example. Let's start by defining a class which holds a list of constraints, and has a resolve method to work out a final value from those constraints. As I mentioned earlier, in this article we won't concern ourselves with how we calculate that value, right now we're just interested in how we might represent objects which might be constrained:

class ConstrainedValue():
    """An object which can be passed around to represent a value."""

    def __init__(self):
        self._constraints: List[Constraint] = []

    def constrain_with(self, constraint):
        """Add a constraint to this objects list of constraints."""
        self._constraints.append(constraint)

    def resolve(self):
        """Leave to specific implementations to calculate the value on the basis
        of constraints."""
        raise NotImplementedError("`resolve` has not yet been implemented.")

Let's also think about what a constraint might look like. I'll define an abstract constraint and the implement the simplest example of a constraint - a constraint which ties the object to a fixed value.

from abc import ABC

class Constraint(ABC):
    """Used to restrict that value of a ```

ConstrainedValue

```."""
    pass

class FixedValueConstraint(Constraint):
    def __init__(self, value):
        self._value = value

    @property
    def value(self):
        return self._value

This really looks like we're getting somewhere. We have a class which represents a constrainable value, and we can apply constraints to it.

So how might we integrate this with a shape? Let's take the simplest of shapes, a point, and see what we might do. A naive implementation of a Point with no ConstrainedValue integration might be:

class Point:
    def __init__(x=None, y=None):
        self._x = x
        self._y = y

    @property
    def x(self):
        return self._x

    @x.setter
    def x(self, value):
        self._x = value

    @property
    def y(self):
        return self._y

    @y.setter
    def y(self, value):
        self._y = value

To stitch our ConstrainedValue into this, we need to modify the initializer so that it creates ConstrainedValue objects; alter the properties so that they add a FixedValueConstraint to the ConstrainedValue; and then use those properties to set the values in the initializer if they are provided:

class Point:
    def __init__(self, x=None, y=None):
        self._x = ConstrainedValue()
        self._y = ConstrainedValue()
        if x is not None: 
            self.x = x
        if y is not None : 
            self.y = y

    @property
    def x(self):
        return self._x

    @x.setter
    def x(self, value):
        self._x.constrain_with(FixedValueConstraint(value))    

    @property
    def y(self):
        return self._y

    @y.setter
    def y(self, value):
        self._y.constrain_with(FixedValueConstraint(value))

So now we can create a Point, assign it some co-ordinates, and have it return a ConstrainedValue for each of those properties:

p = Point(1,2)
print(type(p.x).__name__)
print(type(p.y).__name__)

ConstrainedValue
ConstrainedValue

Getting Value Back

Right now this constrained value isn't a lot of use as there's no way of finding out what the value is. The details of how we do this in general are for a later article, but let's implement a trivial resolve method in ConstrainedValue which simply checks if its constrained with a FixedValueConstraint and if so returns that value, otherwise throws an UnderConstrainedError. This will allow us to play a little more and really check that what we've built so far will work for us:

class UnderConstrainedError(RuntimeError):
    pass

class ConstrainedValue():
    """An object which can be passed around to represent a value."""

    def __init__(self):
        self._constraints: List[Constraint] = []

    def constrain_with(self, constraint):
        """Add a constraint to this objects list of constraints."""
        self._constraints.append(constraint)

    def resolve(self):
        """Naive implementation to aid testing"""
        for constraint in self._constraints:
            if isinstance(constraint, FixedValueConstraint):
                return constraint.value

            raise UnderconstrainedError("Fixed Value has not been provided.")

So now we should be able to ask our Point what the values are of its properties:

p = Point(1,2)
print(f"p.x is {p.x.resolve()}")
print(f"p.y is {p.y.resolve()}")

Which gives us the output we'd expect:

p.x is 1
p.y is 2

This is all well and good. We can create a point and give it values, but as it stands we cannot constrain one point to "point to" another. If create a Point p with some initial values, and then another point q and then set the x value of q to the x value of p, then ask q.x what its value is:

p = Point(1,2)
q = Point()
q.x = p.x
print(f"q.x is {q.x.resolve()}")

then we get a reference to the ConstrainedValue which is p.x instead of 1 as we'd probably expect.

q.x is <test_pysketcher_memoization.test_code_150.<locals>.ConstrainedValue object at 0x106375460>

We can call resolve twice to get the value we want:

p = Point(1,2)
q = Point()
q.x = p.x
print(f"q.x is {q.x.resolve().resolve()}")

q.x is 1

but that is very messy and in complex diagrams we may have to call resolve many times. We could
alter our resolve method to detect if it is about to return a ConstrainedValue and if it is, call resolve() again until such time as it gets to a defined value. I feel its neater, however, to detect if we're assigning a ConstrainedValue. If we are, then instead of adding a FixedValueConstraint we simply set the property to the provided ConstrainedValue.

class Point:
#... 
    @x.setter
    def x(self, value):
        if isinstance(value, ConstrainedValue):
            self._x = value
        self._x.constrain_with(FixedValueConstraint(value))    

#... 
    @y.setter
    def y(self, value):
        if isinstance(value, ConstrainedValue):
            self._y = value
        self._y.constrain_with(FixedValueConstraint(value))

This now gives us more intuitive behavior:

p = Point(1,2)
q = Point()
q.x = p.x
print(f"q.x is {q.x.resolve()}")

q.x is 1

Great!

Let's get the descriptors in

All is not well and good, however. If we look at our Point class we have a code which is repeated for the x and y properties. Moreover this code will need to be repeated for all the properties on all of our shapes, which is far from ideal. It would be much better if we could somehow encapsulate the assignment logic into the ConstrainedValue itself and have that behavior shared across all such objects in PySketcher.

It so happens that there is a way to do this. Python provides a mechanism called a Descriptor which calls a method when a field is set or read. It is a protocol which means that we don't have to explicitly declare that we are creating a Descriptor, we just have to comply with its requirements. In this case defining a __set__, __get__, or __delete__ method is sufficient.

class ExampleDescriptor:
    def __init(self):
        self._value = None

    def __get__(self, instance, type=None):
        print("I am a get method")
        return self._value

    def __set__(self, instance, value):
        print("I am a set method")
        self._value = value

class ExampleObject:
    prop = ExampleDescriptor()


test = ExampleObject()
print("##")
test.prop = 1
print("##")
print(test.prop)
print("##")

##
I am a set method
##
I am a get method
1
##

So by augmenting out ConstrainedValue class with a __get__ and __set__ method, we can move the assignment logic out of the properties in the Point class, and in fact do away with the properties all together.

class ConstrainedValue():
    """An object which can be passed around to represent a value."""
#... 
    def __init__(self):
        self._value = None
        self._constraints: List[Constraint] = []

    def __get__(self, instance, type=None):
        return self

    def __set__(self, instance, value):
        if isinstance(value, type(self)):
            self._value = value
            return

        self.reset_constraints()
        self.constrain_with(FixedValueConstraint(value))


class Point:
    x = ConstrainedValue()
    y = ConstrainedValue()

    def __init__(self, x=None, y=None):
        if x is not None: 
            self.x = x
        if y is not None : 
            self.y = y

p = Point(1,2)
print(f"p.x is {p.x.resolve()}")
q = Point()
q.x = p.x
print(f"q.x is {q.x.resolve()}")

p.x is 1
q.x is 1

Now this is starting to look great! The Point class has a really clean definition and the interface for PySketcher users is intuitive. As is so often the way, all is not as rosy as things might at first appear. Let us investigate using p and q as independent points.

p = Point(1,2)
q = Point(2,3)
print(f"p.x is {p.x.resolve()}")
print(f"q.x is {q.x.resolve()}")

p.x is 2
q.x is 2

Disaster! Both p and q have the same value for x even though we want them to have separate values.

Perhaps a little too constrained

This is because the ConstrainedValue belongs to the class Point not to the instances of class Point, and as such is shared by all the instances of Point. Alas it has to be this way because that's how decorators work. If you would like to read more about decorators there is an excellent article here!, and that very article discusses our exact problem. To fix it we use the __set_name__ magic method which is called on instance creation, and use that to define a field on the instance in which to store our values. This also means we have to separate the data away from assignment logic so that we can store it in the instance, which we shall do in a ConstraintSet object. This is a little neater as the code which assigns the values and deals with the method calls is contained in ConstrainedValue and the code which holds the value and the resolution logic is held in ConstraintSet; so we have better separation of concerns.

class ConstraintSet:
    def __init__(self):
        self._constraints = []

    def constrain_with(self, constraint):
        """Add a constraint to this objects list of constraints."""
        self._constraints.append(constraint)

    def reset_constraints(self):
        """Removes the existing constraints from the constraint set"""
        self._constraints = []

    def resolve(self):
        """Naive implementation to aid testing"""
        for constraint in self._constraints:
            if isinstance(constraint, FixedValueConstraint):
                return constraint.value

        raise UnderconstrainedError("Fixed Value has not been provided.")

class ConstrainedValue:
    """An object which can be passed around to represent a value."""

    def __set_name__(self, owner, name):
        self.public_name = name
        self.private_name = f"_{name}"

    def __get__(self, instance, typ=None):
        # grab the ConstraintSet from the instance
        constraint_set = getattr(instance, self.private_name, None)

        # If the instance didn't have an initialized ConstraintSet then
        # give it one
        if constraint_set is None:
            constraint_set = ConstraintSet()
            setattr(instance, self.private_name, constraint_set)
        return constraint_set

    def __set__(self, instance, value):
        if isinstance(value, ConstraintSet):
            setattr(instance, self.private_name, value)
            return

        constraint_set = self.__get__(instance)
        constraint_set.reset_constraints()
        constraint_set.constrain_with(FixedValueConstraint(value))

class Point:
    x = ConstrainedValue()
    y = ConstrainedValue()

    def __init__(self, x=None, y=None):
        if x is not None: 
            self.x = x
        if y is not None : 
            self.y = y

And this now works:

p = Point(1,2)
q = Point(2,3)
print(f"p.x is {p.x.resolve()}")
print(f"q.x is {q.x.resolve()}")

p.x is 1
q.x is 2

As does our original logic:

p = Point(1,2)
print(f"p.x is {p.x.resolve()}")
q = Point()
q.x = p.x
print(f"q.x is {q.x.resolve()}")

p.x is 1
q.x is 1

And for the icing on the cake, let's validate that when we change the value of p.x, the value of q.x changes with it:

p = Point(1,2)
print(f"p.x is {p.x.resolve()}")
q = Point()
q.x = p.x
print(f"q.x is {q.x.resolve()}")
p.x = 2
print(f"p.x is {p.x.resolve()}")
print(f"q.x is {q.x.resolve()}")

p.x is 1
q.x is 1
p.x is 2
q.x is 2

Making things more explicit

As a little recap, let's review what we've achieved so far. We can create an object which has fields which can have constraints applied to them by creating them as ConstrainedValues at the class level. This results in a set of constraints being stored in a ConstraintSet object at the instance level, and constraints can be added using the constrain_with method. Our fields can either be assigned a value or another ConstraintSet. Value assignment is implemented by, behind the scenes, applying a FixedValueConstraint to the field in question having cleared any previously applied constraints. We have validated this by implementing a Point object with two fields x and y. instantiating this twice, linking the x field of one instance to the other, and validating that when the first is changed, the second changes with it.

Certainly great progress! What might happen if we wanted to reverse engineer this process, however? If we wanted to ask say, q.x, what it is constrained by? At the moment, if we executed print(q.x) it would show the same object as p.x, namely a FixedValueConstraint. Moreover seeing that q.x has been constrained by a FixedValueConstraint may lead a developer to think that a value had been directly assigned to q.x which is not the case. This may be confusing if we're trying to debug a complex diagram. As such let's create an additional constraint, a LinkedValueConstraint, which means we can explicitly model that q.x has been assigned p.x.

Before we do that let's sort out how ConstraintSets are displayed. Right now, if we print one directly, we are given a type and a memory location. Let's override the __repr__ method to give us something a little more meaningful. We'll need to do something similar to FixedValueConstraint as well:

class ConstraintSet:
#... 
    def __repr__(self):
        retval = "ConstraintSet("
        if len(self._constraints) == 0:
            retval += ")"
            return retval

        for constraint in self._constraints:
            retval += f"\n    {constraint}"
        retval += "\n)"
        return retval 

class FixedValueConstraint(Constraint):
#... 
    def __repr__(self):
        return f"{self.__class__.__name__}<{self.value}>"

#... 
p = Point(1,2)
print(p.x)

ConstraintSet(
    FixedValueConstraint<1>
)

Okay, so on to our new constraint. This LinkedValueConstraint will store a link to a ConstraintSet:

class LinkedValueConstraint(Constraint):
    def __init__(self, constraint_set):
        self._constraint_set = constraint_set

    @property
    def constraint_set(self):
        return self._constraint_set

    def __repr__(self):
        return f"{self.__class__.__name__}<{self.constraint_set}>"

A quick test:

p = Point(1,2)
c = LinkedValueConstraint(p.x)
print(c)

LinkedValueConstraint<ConstraintSet(
    FixedValueConstraint<1>
)>

So we can see now that our LinkedValueConstraint is linked to a ConstraintSet which contains a single constraint which is a FixedValueConstraint fixed at 1. This is helpful, but it would be even more helpful if we could link back to p.x itself. The output I would like to see is:

LinkedValueConstraint<p.x>

So let's have a look at what we can do with our ConstraintSet to give it a useful name. The list of all the constraints may well be useful so we'll leave that in __repr__ but we can override __str__ to use the name as an alternative.

We create the ConstraintSet in the ConstrainedValue class, and that is aware of the instance to which the ConstraintSet belongs, so at that point we can pass a name in. Let's update the constructor of ConstraintSet to take a name, and add the __str__ method:

class ConstraintSet:
    def __init__(self, name=""):
        self._constraints = []
        self._name = name
#... 
    def __str__(self):
        return self._name

And update ConstrainedValue to provide that name:

class ConstrainedValue:
    """An object which can be passed around to represent a value."""

#... 
    def __get__(self, instance, typ=None):
        # grab the ConstraintSet from the instance
        constraint_set = getattr(instance, self.private_name, None)

        # If the instance didn't have an initialized ConstraintSet then
        # give it one
        if constraint_set is None:
            constraint_set = ConstraintSet(f"{instance.name}.{self.public_name}")
            setattr(instance, self.private_name, constraint_set)
        return constraint_set

#...

And finally, as there is no easy way to work out the name of the variable to which an instance has been defined, we'll update the Point class to optionally take a name at creation time. This is less than ideal, and I may well fix it later, but I don't want us to get distracted away from constraint modelling!

class Point:
    x = ConstrainedValue()
    y = ConstrainedValue()

    def __init__(self, name="", x=None, y=None):
        self._name = name
        if x is not None: 
            self.x = x
        if y is not None : 
            self.y = y

    @property
    def name(self):
        return self._name

Check that worked:

p = Point('p',1,2)
print(p.x)
c = LinkedValueConstraint(p.x)
print(c)

p.x
LinkedValueConstraint<p.x>

Now let's stitch this into our __set__ method in the ConstrainedValue class:

class ConstrainedValue:
    """An object which can be passed around to represent a value."""
#... 
    def __set__(self, instance, value):
        # Grab the ConstraintSet from the instance
        constraint_set = self.__get__(instance, None)

        constraint_set.reset_constraints()
        # if the value we've been asked to assign is a ConstraintSet
        # then add a LinkedValueConstraint: 
        if isinstance(value, ConstraintSet):
            constraint_set.constrain_with(LinkedValueConstraint(value))
            return

        # otherwise use a FixedValueConstraint to constrain to the provided
        # value
        constraint_set.constrain_with(FixedValueConstraint(value))

#...

Finally let's tweak our resolve method on the ConstraintSet so that it understands what a LinkedValueConstraint is. Remember this method is only a place holder and the real logic of calculating values we'll deal with in a later article.

class ConstraintSet:
    def __init__(self, name=""):
        self._constraints = []
        self._name = name
#... 
    def resolve(self):
        """Naive implementation to aid testing"""
        for constraint in self._constraints:
            if isinstance(constraint, FixedValueConstraint):
                return constraint.value
            if isinstance(constraint, LinkedValueConstraint):
                return constraint.constraint_set.resolve()

        raise UnderconstrainedError("Fixed Value has not been provided.")

#... 
    def __str__(self):
        return self._name

And now everything should work end to end:

p = Point('p', 1,2)
q = Point('q')
print(f"p.x is {p.x}")
print(f"p.x resolves to {p.x.resolve()}")
q.x = p.x
print(f"q.x is {repr(q.x)}")
print(f"q.x resolves to {q.x.resolve()}")
p.x = 2
print(f"Now p.x has changed, q.x resolves to {q.x.resolve()}")

p.x is p.x
p.x resolves to 1
q.x is ConstraintSet(
    LinkedValueConstraint<p.x>
)
q.x resolves to 1
Now p.x has changed, q.x resolves to 2

Are we done? Not just yet. We can constrain a property to another property, which is helpful, but there are scenarios where we'll need to do more than that. We may, for example, wish to constrain a Point to being on a line, or on the circumference of a circle. To do this, constraining the properties independently isn't sufficient. We need to be able to constrain the Point (or indeed any shape) and have that constraint, in turn, constrain the properties of that Point (or shape). This article, is however, long enough. We shall deal with that in part two!