Another PartTree question

[dibyendumajumdar]

Another question - in the part tree how are nodes compared? I am trying to understand the semantics for code such as:

part_tree.parent_node((seq_model.gaps[-1], seq_model.z_dir[-1]))

leading to

leaf_node = self.node(obj)

leading to

    def node(self, obj):
        """ Return the node paired with `obj`. """
        return find_by_attr(self.root_node, name='id', value=obj)

Which eventually leads to == operator being used; but I am not sure how and where the meaning of == is defined.

[mjhoptics]

I assume they're compared in the same way as keys are compared in python. It seems to work that way, at least.

Each node in the part_tree has the additional attributes name, id, and tag. The id may be an object or a tuple, just like a key for a dict. Most times I just have an object instance as a node id. Gaps are a special case in that they are used one way in element-land but the same gap can appear multiple times in double pass systems. This is a case where element model information can help to enforce correctness in multipass sequential models. So the gap in a sequential model is a combination of the gap and the z_dir for that segment. In the element model, the gap is only present once, and both sequential gaps will have it as the parent_node.

I've done a lot recently with the part_tree, adding assemblies for collections of parts, and being able to flip a subsection of a sequence. We need to integrate what you've done with typing into the code base soon.

[dibyendumajumdar]

So that means objects are being compared by identity - i.e. they are equal if they are the same instance. From Python docs:

The default behavior for equality comparison (== and !=) is based on the identity of the objects. Hence, equality comparison of instances with the same identity results in equality, and equality comparison of instances with different identities results in inequality. 

[dibyendumajumdar]

I've done a lot recently with the part_tree, adding assemblies for collections of parts, and being able to flip a subsection of a sequence.

Is this in code not yet committed to the repo - or are you referring to the work done last year?

[mjhoptics]

I haven't updated this to the repo yet. I keep adding to it and breaking it.

[dibyendumajumdar]

I also noticed that the elements in ElementModel do not have a class hierarchy; they are used more like duck typing. Is that a deliberate design choice?

[mjhoptics]

I've added a Protocol class called Part to the hierarchy.

class Part(Protocol):
    """Abstract base class for all types of elements. """
    label_format: ClassVar[str]
    label: str
    parent: Any
    is_flipped: bool = False

    @abstractmethod
    def flip(self):
        self.is_flipped = not self.is_flipped

    @abstractmethod
    def sync_to_restore(self, ele_model, surfs, gaps, tfrms):
        raise NotImplementedError

    @abstractmethod
    def sync_to_update(self, seq_model: SequentialModel):
        raise NotImplementedError

    @abstractmethod
    def tree(self, **kwargs) -> Node:
        raise NotImplementedError

    @abstractmethod
    def reference_interface(self) -> Interface:
        raise NotImplementedError

    @abstractmethod
    def reference_idx(self) -> int:
        raise NotImplementedError

    @abstractmethod
    def interface_list(self) -> List[Interface]:
        raise NotImplementedError

    @abstractmethod
    def gap_list(self) -> List[Gap]:
        raise NotImplementedError

    @abstractmethod
    def update_size(self) -> None:
        raise NotImplementedError

    @abstractmethod
    def render_handles(self, opt_model) -> Dict[str, GraphicsHandle]:
        raise NotImplementedError

    @abstractmethod
    def handle_actions(self) -> Dict[str, Any]:
        raise NotImplementedError

[dibyendumajumdar]

cool

[dibyendumajumdar]

We need to integrate what you've done with typing into the code base soon.

There is still a lot to do but its a bit frustrating that Python doesn't handle cycling dependencies very well. It means as it stands some annotations cannot be added.

[mjhoptics]

I think there is benefit even if technical issues get in the way of covering everything completely. There is clearly a tension between the original idea of Python as a loosely typed language and the desire to add typing to improve program definition.

I haven't done much with git and PRs but one approach seems like to get your typing branch merged onto a typing branch in the main repo, and then merge to the master branch from there. We could keep the typing branch alive for future work, merging to master as needed. I may misunderstand this process so if you have alternative thoughts, please let me know.