Hi @RazerM, thanks for the contribution, and thanks for your patience awaiting review!

I'm trying to make sure I understand the consequences of this change.

It seems that by returning NotImplemented, we would be allowing the possibility for other objects to declare themselves equal to a BaseFigure (or BasePlotlyType) object, if they choose.

I'm having trouble thinking of a scenario where that would be helpful. It's possibly something that could be useful to us internally within plotly.py, but we haven't encountered a need for it yet to my knowledge. Do you have a scenario on your end that would benefit from this change?

we would be allowing the possibility for other objects to declare themselves equal to a BaseFigure (or BasePlotlyType) object, if they choose.

Yes, but they can already do that as long as they're on the LHS. plotly should return NotImplemented so that equality is symmetric (A == B means B == A).

Some use cases are:

• a test helper such that I can do e.g. assert figure == snapshot. The snapshot object would serialize to a snapshot file if it does not exist, or if it does deserialize it and then return the comparison result. Right now I have to do assert snapshot == figure.

• SQL query builders etc. overload __eq__. E.g. imagine I have an SQLAlchemy type which can serialize figures. This should work symmetrically:

  select().where(my_figure == MyModel.figure)  # right now this is `.where(False)`!
  select().where(MyModel.figure == my_figure)
  

See also django/django#11808, sympy/sympy#13078 for examples in other popular projects.

we would be allowing the possibility for other objects to declare themselves equal to a BaseFigure (or BasePlotlyType) object, if they choose.

Yes, but they can already do that as long as they're on the LHS. plotly should return NotImplemented so that equality is symmetric (A == B means B == A).

Good point, that's a solid argument in favor. Thanks for the other examples as well. I'll approve!