My attention was drawn today to a variation of this behaviour:
In [15]: import openmath.openmath as om
In [16]: a = om.OMObject(1, 2)
In [17]: b = om.OMObject(1, '2')
In [18]: a == b
Out[18]: False
In [19]: a
Out[19]: OMObject(1, version=2, id=None, cdbase=None)
In [20]: b
Out[20]: OMObject(1, version='2', id=None, cdbase=None)
In [21]: a.version
Out[21]: '2'
In [22]: b.version
Out[22]: '2'
which shows that we're not using CaseClass the way it is supposed to (we should not modify parameters in __init__, that is).
It is unfortunate that Python has no decent way of implementing structs with inheritance (I won't go as far as calling them algebraic datatypes), but I think we should stick to something simpler and more pythonic.
I'm working on a few-lines-solution (ab)using named tuples, I'll link it shortly. That would also have the benefit of eliminating one dependency.
I'd be interested in hearing your opinion, @tkw1536.
My attention was drawn today to a variation of this behaviour:
which shows that we're not using
CaseClassthe way it is supposed to (we should not modify parameters in__init__, that is).It is unfortunate that Python has no decent way of implementing structs with inheritance (I won't go as far as calling them algebraic datatypes), but I think we should stick to something simpler and more pythonic.
I'm working on a few-lines-solution (ab)using named tuples, I'll link it shortly. That would also have the benefit of eliminating one dependency.
I'd be interested in hearing your opinion, @tkw1536.