Fix __eq__ and __ne__ for classes implementing them

[alexer]

Main issue, which concerns Vector, Location, and ShapeList:

Comparison with an object of a different type should not cause an exception - they are simply not equal. Raising an exception in __eq__ can (and will*) break unrelated code that expects __eq__ to be well-behaved.

(* I noticed this bug when cq-editor choked on it while trying to find a name for an object in a dictionary of local variables)

There's a second more minor issue, which concerns the rest of the classes:

When the other type in __eq__ is not supported, one should technically return NotImplemented instead of False, to allow the other type to take part in the comparison, in case they know about our type.

(__ne__ should also not generally be implemented as just the negation of __eq__ because of this, but the one for Plane can just be removed - Python will automatically do the right thing based on __eq__ there -- ShapeList, on the other hand, needs to also have its __ne__ overridden, because it directly subclasses list, which already implements it)

Technically, the __eq__ for Vector and Plane is also broken in another way: It's not transitive.

>>> a, b, c = Vector(0), Vector(9e-6), Vector(18e-6)
>>> a == b == c
True
>>> a == c
False

They should really eg. have a separate is_close() or something for approximate comparison, but this isn't fixed here, since I have no idea how many places it'd break, for one.

I also noticed that Shape.__eq__ calls Shape.is_same instead of Shape.is_equal which just seems... wrong.

[gumyr]

Thanks! A lot of effort has been put into making the code fully align with Python (the original CadQuery code which this is based off didn't follow Python conventions) but this was area that needed work.

You are correct that Shape.__eq__ isn't really doing what an == operator should do but there is no way to compare CAD models to create the == operator otherwise. Too Tall Toby uses a volume (actually weight) comparison but that can easily be shown to be incomplete.

With respect to the transitive property, I don't know of a way to solve this problem given some tolerance must be provided. The Python isclose function works with tolerance values too. If you know of a robust solution to this please let me know.