str/repr/description fixes

[IgnaceBleukx]

So I encountered some typing issues from an unexpected angle: printing of constraints...

This PR does two things:

1. Whenever a description is used as a subexpression, current master uses that description as part of the __repr__ call of the parent. This may cause some issues when we have two subexpressions with the same description...
2. Printing of NDVarArrays vs lists: the former does not add a "," while the latter prints ", " between each element. Additionally, we also had a special case for printing when an ndarray is used as an arg (but not the only arg), which matched neither printing of ndvararray nor printing of list and used "," between each arg (without the space)

I'm undecided on how to tackle the Element case, I currently use to_list when the array is a numpy array, but that is overkill of course...
Alternatively, we just add __str__ and __repr__ overload for Element

[tias]

I don't fully get the problem...

• is it an actual typing issue? it all returns string?
• is it about the ',' use being inconsistent?

or is it about a much harder question: how to 'nest' human descriptions of nested expressions? This one... I'm not sure what the use case is, and whether we should do it at all...

Perhaps overwriting str/repr is not the right way to show descriptions, and we should have made a get_description() like we have a set_description()?

Finally, I don't even know the real Python-intended difference between 'str' and 'repr' and whether/how we can follow the intended difference?

[IgnaceBleukx]

So what I meant with typing issue is the difference between having an NDVarArray as an argument and a list as an argument changes how the expression is printed (the "," vs ", " thingy).

I'm pretty sure that __str__ is indeed the right way for printing the description of an expression.
https://stackoverflow.com/questions/1436703/what-is-the-difference-between-str-and-repr

So, __str__ should return a human-readible representation of the expression, while __repr__ should return an unambigous string representation of the expression (which is what we actually use for hashing).

For handling nested descriptios, I think the approach I impemented in this PR is fine? Just print the description if you are making a human-readible string representation no matter if the expr is a subexpression or not; otherwise use your __repr__.
The immediate use-case I can think of is when printing an assump_model in our explanation work.