@vmoens I have a question about the following case: when installed version of the module doesn't fit any implementation.
For example: we have gym 0.26 and 2 functions with implement_for('gym, '0', '0.24')and implement_for('gym, '0.24', '.25').
Currently, I implemented the decorator, so it just returns the latest declared implementation, but I thought about more strict behaviour, when decorator returns a function, that raises an error (something like "Installed version of 'gym' is not supported), so when the function (with @implement_for) is called this exception is raised.

Which one is preferable from your perspective?

Currently, I implemented the decorator, so it just returns the latest declared implementation, but I thought about more strict behaviour, when decorator returns a function, that raises an error (something like "Installed version of 'gym' is not supported), so when the function (with @implement_for) is called this exception is raised.

One option could be that if we use @implemented_for we must cover all versions:

@implemented_for("gym", None, "0.13")
def fun():
   foo()
@implemented_for("gym", "0.13", None)
def fun():
   foo()

is valid but

@implemented_for("gym", None, "0.13")
def fun():
   foo()
@implemented_for("gym", "0.13", "0.14")
def fun():
   foo()

will return an exception during import.

There are caveats with this (it's an optimistic view on future releases), but at least if nothing is expected to break with a new release our CI will just pass. If something breaks, it means we need one more function implementation.

What do you think?

With what I suggested as more strict option there won't be an import time exception. The decorated function will become something like:

def fun():
   raise NotImplementedError("Installed version of 'gym' is not supported")

So exception will be thrown only if fun() is actually called, despite the unsupported version, so it should not break CI if the test is skipped. I was thinking to do the same for missing module.

Such strict behaviour is not typical for python and forcing user to implement "extra" functions might not be a good idea, that is why I decided to implement it like I did. Unless, you think that catching the situation when function is called with unsupported (potentially) version of a module beforehand is more often beneficial than inconvenient.

Also, I just realised that I haven't considered "from_version" as None for some reason, but it does look reasonable to allow it, I will do it.

Codecov Report

Merging #618 (37c481d) into main (dd9a98f) will decrease coverage by 0.09%.
The diff coverage is 90.47%.

@@            Coverage Diff             @@
##             main     #618      +/-   ##
==========================================
- Coverage   87.92%   87.82%   -0.10%     
==========================================
  Files         125      125              
  Lines       24218    24280      +62     
==========================================
+ Hits        21293    21324      +31     
- Misses       2925     2956      +31     

Flags with carried forward coverage won't be shown. Click here to find out more.

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

So exception will be thrown only if fun() is actually called, despite the unsupported version, so it should not break CI if the test is skipped. I was thinking to do the same for missing module.

Such strict behaviour is not typical for python and forcing user to implement "extra" functions might not be a good idea, that is why I decided to implement it like I did. Unless, you think that catching the situation when function is called with unsupported (potentially) version of a module beforehand is more often beneficial than inconvenient.

My suggestion was a bit in the spirit of @abc.abstractmethod where you get an error at loading time if something is not implemented. But an error during execution is equally fine!

So exception will be thrown only if fun() is actually called, despite the unsupported version, so it should not break CI if the test is skipped. I was thinking to do the same for missing module.
Such strict behaviour is not typical for python and forcing user to implement "extra" functions might not be a good idea, that is why I decided to implement it like I did. Unless, you think that catching the situation when function is called with unsupported (potentially) version of a module beforehand is more often beneficial than inconvenient.

My suggestion was a bit in the spirit of @abc.abstractmethod where you get an error at loading time if something is not implemented. But an error during execution is equally fine!

Alright, I will change the behaviour, so the decorator will replace the function with a mock that raises the exception by default (until fitting implementation found).
Plus, I missed the case when two functions in different modules have the same name, I will fix it.