Use of 'param' package

[LiamPattinson]

The Python package param was recently brought to my attention, which solves the same problem as my own new library proper_tea, although it does so using 'descriptors' and a lot of metaclassing rather than property factories. As it's a much more mature library, it's likely to be more stable over time and is more feature-rich. On the other hand, I quite like the interface I've created. For a positive float in proper_tea, the user requires:

class MyClass:
    val = proper_tea.positive_float()

Whereas in param, the user must specify bounds explicitly and inherit from a base class:

class MyClass(param.Parameterized):
    val = param.Number( bounds=(0,None))

A significant advantage of param is that it offers better error messages when things go wrong. If you tried setting val to -5 in each case, param would tell you that there was an error with 'Parameter val', while proper_tea only knows that a property setter in 'MyClass' has gone wrong. I think I'll need to get into metaclassing before I can solve that problem myself.

Do you think it would be worth refactoring to use param instead? I believe it should be possible to do so without changing any of the tests.

[shimwell]

This is a tricky subject, there are a few packages that offer validation of inputs such as Param and Pydantic.

What I've also observed is that core Python also gradually incorporates features of such packages as they are shown to be valuable. Perhaps one day such checking features will be built into Python standard libraries.

It largely depends on your plans with proper_tea , for example will it be maintained, checked with new versions of python as they come along etc.

I think you are the expert here @LiamPattinson and we will follow your recommendation.