Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enforce user to specify a value #574

Closed
MarcSkovMadsen opened this issue Nov 22, 2021 · 2 comments
Closed

Enforce user to specify a value #574

MarcSkovMadsen opened this issue Nov 22, 2021 · 2 comments
Labels
type-feature Feature request

Comments

@MarcSkovMadsen
Copy link
Collaborator

I am designing a Parameterized class that requires some of the parameters to be set on instantiation.

I would expect the below to raise an error. But it does not

import param
class CronjobSpec(param.Parameterized):
    schedule = param.String(default=None, allow_None=False)

CronjobSpec()

Workaround

If I create a custom __init__ I can get it working.

import param
class CronjobSpec(param.Parameterized):
    schedule = param.String()

    def __init__(self, schedule: str, **params):
        super().__init__(schedule, **params)

CronjobSpec()
$ python 'script.py'
Traceback (most recent call last):
  File "script.py", line 8, in <module>
    CronjobSpec()
TypeError: __init__() missing 1 required positional argument: 'schedule'
@MarcSkovMadsen MarcSkovMadsen added type-feature Feature request TRIAGE User-submitted issue that hasn't been triaged yet. labels Nov 22, 2021
@maximlt maximlt removed the TRIAGE User-submitted issue that hasn't been triaged yet. label Nov 22, 2021
@jbednar
Copy link
Member

jbednar commented Nov 23, 2021

Congratulations! You've made a duplicate of the very first issue ever opened on the Param github repo: #1 . :-) Another user also requested this recently, on some other forum (Stackoverflow, maybe?). It's related to #97 , in that I think we should define a non-None value that is Undefined or NotImplemented, to distinguish between a valid value of None and an invalid value that should force inheritance from a superclass and eventually error if not ever set.

I'd be happy for someone to investigate what it would take to close issues 1 and 97, which I don't think is difficult but requires some work to see what sentinel value is appropriate and whether we can preserve backwards compatibility properly if we change various None defaults to this sentinel. I'll close this issue as a duplicate, but it's still a valid request!

BTW, detecting the case you showed above is tricky, because allow_None is False by default, and so specifying it explicitly like that has no effect. It then falls down to the logic that infers that if a user creates a Parameter with a default value of None, None must be allowed, which is generally true but not your intention in this case. Detecting that you had specified allow_None=False explicitly would require something like making it None by default, treating that like False, and then raising an error in the above code. I suppose that would be a way to achieve what you are requesting (and what #1 requests) without a new sentinel value, but I'm not sure it's clearer.

@maximlt
Copy link
Member

maximlt commented Apr 15, 2023

As mentioned above, this is a duplicate of #1

@maximlt maximlt closed this as completed Apr 15, 2023
@maximlt maximlt removed this from the Wishlist milestone Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-feature Feature request
Projects
None yet
Development

No branches or pull requests

4 participants