Fixed typing of arithmetic methods

[RobbieKiwi]

Closes #435.

Changes proposed in this Pull Request

Arithmetic methods now understand that data array is a valid type for addition/multiplication

Checklist

• Code changes are sufficiently documented; i.e. new functions contain docstrings and further explanations may be given in doc.
• Unit tests for new features were added (if applicable).
• A note for the release notes doc/release_notes.rst of the upcoming release is included.
• I consent to the release of this PR's code under the MIT license.

[lkstrp]

Thanks @RobbieKiwi, that was annoying. Could you also add the missing lines to the test and resolve the other mypy warnings?

[RobbieKiwi]

Is there a reason why one of these should work and the other should give a type error?
x + x * y + 5
5 + x * y + x

[RobbieKiwi]

@lkstrp I went down a bit of a rabbit hole with the typing in order to make sure the type checker could tell the difference between a LinearExpression and QuadraticExpression which involved breaking the inheritance between the two and making a base class. Could you please have another look?

[FabianHofmann]

impressive work @RobbieKiwi ! @lkstrp or I will go through it soon! we'll make another release today but this will definitely go into the next one!

[FabianHofmann]

@RobbieKiwi do you remember why the merge function now requires a cls argument? I recon that it is a bit inconvenient for users...

[RobbieKiwi]

@RobbieKiwi do you remember why the merge function now requires a cls argument? I recon that it is a bit inconvenient for users...

@FabianHofmann Now that LinearExpression and QuadraticExpression are separated this function would need some generic type matching to properly return the right type without mypy complaining. Expressing this just using the input expressions is impossible because of the complicated combination (LinearExpression + QuadraticExpression -> QuadraticExpression). Instead I opted for matching the type on the passed cls.

The cls is still an optional parameter. If you don't pass it then you get mypy warnings in the CI pipeline and runtime warnings.
If you like I could have another look at it and find a way to get rid of the runtime warning?

[FabianHofmann]

thanks @RobbieKiwi ! that makes sense. atm we are just getting quite some deprecation warnings as we have not set the cls argument and I was wondering whether we couldn't do some sort of auto-detection like for example in pd.concat where you also can pass a series or dataframe. but it feels this won't be compatible with mypy.
if you have a some spare time to think about how we could get rid of the runtime warning, that would be great. perhaps we could also just set the default of cls to LinearExpression?