But given that only dates are directly supported (Parameter types — param 1.12.0.post3+g78e2ea4 documentation)
For historical reasons, the
param.Date Parameter type supports both date and datetime types, despite its name; we later added
CalendarDate for values specific to dates only. So unless I’m misunderstanding, it’s not true that only dates are directly supported in Param.
But it seems that Date does not work with allow_None (https://github.com/holoviz/param/issues/578)
To be more specific, serialization of Dates did not support None; Date and CalendarDate have always supported None. Thanks to Marc’s bug report, a fix for serializing None in Date and various other fancy types has just been merged to master and will be in the next Param release. So far None hasn’t come up for serializing those types, because we use serialization primarily for communicating with a GUI, and (unfortunately) the available GUI widgets do not support None in any case.
Is this documented in the user guide or tutorial? I wasnt aware that Param had any way to have custom parameters.
Yes, Parameters and Parameterized objects — param 1.12.0.post3+g78e2ea4 documentation covers how to write a custom Parameter class, but it shouldn’t be needed in this case, as None is already allowed for Dates and similar types. Users are definitely encouraged (a) to avoid custom types when there is already a suitable type available, but (b) to add a custom type wherever it makes sense, so that they can maintain tight control over allowable values in their applications.
I cannot recommend Param if even a trivial example from pydantic docs takes this much work and exposes trivial misfeatures.
It’s unlikely that code for any library can trivially be adapted to use another library unless at least one of the libraries was written with the other in mind. Pydantic was written independently of Param, about 14 years later than Param, and so it focuses on the specific use cases of Pydantic’s author (REST APIs and Django initially, I think). Param focused on quite different use cases (batch job configuration + optional native OS GUI support initially), with serialization added relatively late in its lifetime and used in relatively few of its applications. So it’s not surprising that there are holes in Param’s serialization support, just as there are plenty of things implemented in Param but not (yet?) in Pydantic.
For users, it would be great to smooth the transition from Pydantic to Param, so that people could more easily make use of Param’s additional features where they are desired. So it would be amazing if a Pydantic user who is interested in something provided by Param would exercise the parts of Param that correspond to Pydantic, submitting detailed bug reports, PRs, and docs that help smooth that transition. E.g. I’d love to see a user guide page explaining how to use Param with Pydantic classes or for Pydantic users, letting people pick the best library for the task they are doing without getting stuck in one moat or the other.