Use "equals" instead of undefined "=="

[le-schmidt]

I found two cases in "ast_utils.py" and "unit_type_symbol.py" where "==" comparison is used without an implemented "_eq_" method. I fixed it for me by switching to the implemented "equals" method, but maybe it would be smarter to implementing "_eq_" and calling equals there

[clinssen]

Thanks for the fix!

Could you give an example situation/run where this would otherwise fail? Normally I would ask to add a unit test, but maybe this is overkill for this change.

Do you have any thoughts on whether we should consistently change the equals() method on Symbols to __eq__()?

Could you please pull the latest master so the tests pass? Sorry, this was due to an unrelated upstream NEST Simulator change.

[le-schmidt]

After looking a bit more into it, it seems like it came down to how the spinnaker generator is set up, so currently not relevant for the main branch. But for future reference, here is what I found.
When generating the iaf_psc_delta model with spinnaker codegenerator in the comparisons mentioned in the above pull requests, the same UnitTypes are different objects, so that the "==" comparison returns false, even though from debugging I found, that they are the same unit. This leads to what seems to be an infinite loop. The same is not the case when using the same setup, but using the generate_nest_target() method. Anyway, it may not be intended to compare object references here, but the object contents. I would probably stay with the "equals" variant, as it seems more in line with all the other symbols and classes used in nestml. There also may be more occurrences that show this behavior, these two are the only ones I stumbled across.

[clinssen]

cheers!