Fusion API and Scripts
Got a new add-in to share? Need something specialized to be scripted? Ask questions or share what you’ve discovered with the community.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

fusion objects return wrong comparison result

Message 1 of 2
174 Views, 1 Reply

fusion objects return wrong comparison result

I'm not sure whether to classify this as a bug, or make this more of a request for F360 API to be consistent and ensure that __eq__ methods (and other comparisons) of any F360 object (probably anything derived from Base) return "NotImplemented".  That is, if the comparison doesn't make sense. 


Python is supposed to reflect the arguments if the first comparison returns "NotImplemented", but if the first argument returns False then it is considered to have been evaluated, and possibly incorrectly.  At the moment, any BrepFace object (in particular ) gives wrong results depending on the order of the arguments.


For example, if I create a class that includes BrepFace as a property, I can include  an __eq__ method


Class Object():
  def __init__(self, face, a, b ....)
     self._face = face
     self.a = a

  def __eq__(self, other):
     if other.objectType == adsk.fusion.BRepFace.classType():
          return other == self._face
     return NotImplemented



such that 


testFace = Object(face)

where face is adsk.fusion.BrepFace



Problem comes when you attempt something like this:


1:  testFace == face  -> True
2:  face == testFace -> False
3:  faces = [testFace, testFace1, ...]
    face in faces -> gives wrong result, False

    where testFace, testFace1 etc are different instantiations of the same Object Class



 #1 above is the equivalent of testFace.__eq__(face) - which works as expected


and in #2 the equivalent is 


face.__eq__(testFace) which should return "NotImplemented", because face doesn't know anything about Object class.  Python is expected to inherently reflect the arguments and execute #1 instead, but won't know if anything is wrong, and returns False


#3 - will always give an incorrect result because the comparison is the equivalent of face.__eq__(testFace)


I don't think I'm wrong, but it wouldn't be the first time



I'm not an expert, but I know enough to be very, very dangerous.

Life long R&D Engineer (retired after 30+ years in Military Communications, Aerospace Robotics and Transport Automation).
Tags (2)
Labels (1)
Message 2 of 2
in reply to: pludikar



I agree with your assessment. I filed issue FUS-70713 to track this.



Kris Kaplan

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th

Autodesk Design & Make Report