Alternative to inheriting from parameterized

[ceball]

See #435

This isn't ready for any kind of review, it's just for visibility. I debated whether or not to make a PR at this stage; I'd say it's in the same kind of category as #252 in terms of speculative nature (though there is a bit more chance I'll work on this one), so we could close and leave just the corresponding issue.

[jbednar]

Looks cool! Is there any downside other than not supporting Python2?

[ceball]

Is there any downside other than not supporting Python2?

Got to test it, got to document it, etc 🤣

I'll answer seriously at some point. But "got to document it" is partially serious already; the more ways to use param:

1. the more documentation to write
2. the more confusing it can be to newcomers
3. the more confusing it can be when coming to "parameterized" code (currently, you definitely know what to expect when you encounter code using param)

I feel like 1 and 2 will be ok, because I can see a story about ways to start using param that makes sense.

3 I'm not sure about. If this PR ends up offering a different way to get to the same behavior as current param, there's no issue. If it ends up allowing people to get bits of param, it might result in more confusing code. Not sure.

[coveralls]

Coverage decreased (-0.3%) to 79.117% when pulling b77d4800c9f576e9824b613a0564ba33c5e3fc7e on gradual_param into b785c42e8745644ad74aa0ace758925f311443e1 on master.

[jlstevens]

Definitely an interesting idea!

Being able to use parameters without inheritance is not something I would recommend when starting from scratch but as a way to help migrate to param it seems very useful.

[jbednar]

Would this approach allow implementing a @param.dataclass decorator that could be used to turn a Python dataclass into something behaving like Parameterized, at least for the types that can be expressed by a dataclass (i.e. not bounds, etc.)?

[droumis]

Closing for now because of incompletion