Maximize compatability with Datatypes by returning NotImplemented if __add__, __mul__ ... fail

[FBumann]

Closes # (if applicable).

Changes proposed in this Pull Request

Arithmetic Operations with custom classes, which rely on xarray or another compatible Datatype are now able to define how they interact with linopy.Variable, linopy.LinearExpression and linopy.QuadraticExpression

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.

[FBumann]

Fell free to remove the tests I created. But they are the best explanation I can give on what the functionality is supposed to do

[FBumann]

Do I need to put some extra work in to get this PR merged like achieving full code coverage? Just let me know. I have little experience in contributing to other packages.

[lkstrp]

Thanks for your contribution @FBumann ! And welcome!

In General the CI checks should all pass. Some checks are sometimes unstable, but "Check Types" and Code Coverage should always pass. Which means extra tests are always needed, so your tests are great!

• For Code Coverage you need to add some Tests, which checks for the NotImplemented Error as well.
• The mypy issues you can find here or run mypy locally

Otherwise you just need to wait for a Review, which sometimes can take a couple of days.

Looks fine for me, when the tests run through. But I give @FabianHofmann the honor to merge.

[lkstrp]

.. means this is commented out, please remove it for your note and the "upcoming version" header

[FabianHofmann]

that's a very interesting thing! out of curiosity, how do you plan to use it? different kind of arrays like polars or so?

[FBumann]

that's a very interesting thing! out of curiosity, how do you plan to use it? different kind of arrays like polars or so?

Im working on a project for Energy System Modeling, comparable to oemof-solph. We just included Linopy as an alternative to pyomo into our project. Currently we evaluate entirely switching to linopy.
Part of our framework is some amount of TimeSeries Management, which is done in a custom class. This class basically stores data and does things like filtering, indexing and other (currently not that much and nothing complicated).
The underlying data is used to create linopy.constraints.
The PR enables us to directly perform + - * / operations with the variable, instead of accessing the correct attribute.
This enables us to write more concise Constraints and perform all Time Series Management in the custom class.

See here (class TImeSeries)

Instead of:

var_x * time_series_a.attribute

we can write

var_x * time_series

Its a small but appreciated improvement in readability

[FBumann]

@FabianHofmann All tests passed. Code coverage increased. Please merge PR