fusion objects return wrong comparison result

[pludikar]

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


  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

Peter 

[KrisKaplan]

Peter,

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

Kris