Support declaring a Parameterized class as an ABC

[maximlt]

Param has its own way of declaring "abstract" classes by annotating them with __abstract = True. Parameterized classes all have an abstract property inherited from the metaclass that returns whether this attribute (mangled) was set. The concrete_descendents function uses _is_abstract to build a collection of the non-abstract descendents only. #84 suggests replacing this approach by Abstract Bases Classes. This MR doesn't replace the current mechanism (we'd need to deprecate it first) but instead attempts to add support to ABCs, allowing users to declare a Parameterized ABC.

To avoid metaclass conflicts, it introduces the ParameterizedABCclass that users must inherit from when they want to declare an ABC.

import abc
import param

class ModelABC(param.parameterized.ParameterizedABC):

    x = param.Number()
    y = param.Number()

    @abc.abstractmethod
    def run(self):
        """This must be implemented by subclasses."""

class BadModel(ModelABC): pass

class GoodModel(ModelABC):
    def run(self):
        return self.x * self.y

try:
    BadModel()
except Exception as e:
    print(repr(e))
    # TypeError("Can't instantiate abstract class BadModel without an implementation for abstract method 'run'")

gm = GoodModel(x=10, y=2)
print(gm.run())
# 20

print(param.concrete_descendents(ModelABC))
# {'GoodModel': <class '__main__.GoodModel'>}

---

@sdc50 I know your comment on #84 dates a little (5 years :) ). If you're still interested in this feature, let me know what you think about it. On the HoloViz code bases side, I think we'll need to see whether we can effectively replace __abstract = True.

• Documentation
• Add more tests

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.93%. Comparing base (b95d476) to head (ce27b13).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1031      +/-   ##
==========================================
- Coverage   88.12%   87.93%   -0.19%     
==========================================
  Files           9        9              
  Lines        4857     4875      +18     
==========================================
+ Hits         4280     4287       +7     
- Misses        577      588      +11     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jlstevens]

Looks good to me!

The only thing I want to see before this is merged are some tests making sure the decorators used to declare abstract methods, properties etc. work as expected.

In an ideal world we would run the whole test suite again using ParameterizedABC to check everything else works but that seems overkill, especially as this base class is opt-in.

[maximlt]

@jlstevens I have added some tests and updated the documentation. I also added ParameterizedABC to the top-level module.

[jlstevens]

Maybe it is worth adding a follow on sentence to strongly recommend not mixing approaches? Having two inconsistent ways of checking if a class is abstract sounds like a recipe for confusion!

That said, maybe param could have a wrapper utility that tries inspect.isabstract(class) first and if that returns False, checks again the param way?

[maximlt]

Comment added in ce27b13

That said, maybe param could have a wrapper utility that tries inspect.isabstract(class) first and if that returns False, checks again the param way?

Internally, we have the _is_abstract function that does exactly that. I don't really want to make it public though:

• Parameterized classes have an abstract property (that's documented too, I checked) that accounts for both approaches
• The less public API the better
• Ultimately, the goal would be to deprecate and remove the old abstract way

If people feel strongly about it, we can add it in another release anyway.

[jlstevens]

The additional tests and documentation as well as the import change all look good to me!

Made one comment to address but otherwise happy to approve and see this merge once the tests and issue merging to main are sorted.