Community
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.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

fusion objects return wrong comparison result

1 REPLY 1
Reply
Message 1 of 2
pludikar
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
     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 

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)
1 REPLY 1
Message 2 of 2
KrisKaplan
in reply to: pludikar

Peter,

 

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

 

Kris



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