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

Instance(..., allow_none=False) is not typing-friendly #1673

Open
mdickinson opened this issue Jul 21, 2022 · 2 comments
Open

Instance(..., allow_none=False) is not typing-friendly #1673

mdickinson opened this issue Jul 21, 2022 · 2 comments
Labels
component: core Issues related to the core library component: typing stubs Issues related to the mypy typing stub files type: enhancement

Comments

@mdickinson
Copy link
Member

Given an Instance trait declaration that uses allow_none=False, for example as in:

class A(HasTraits):
    foo = Instance(SomeClass, allow_none=False)

it would be useful for typing tools to be able to deduce that if a is an instance of A then a.foo is an instance of SomeClass, and in particular is not None.

There are currently two problems with this:

  1. there's no obvious way to indicate to the typing machinery that Instance(...) can't be None when allow_none=False
  2. it's not actually true that allow_none=False means that a.foo can't be None: if no explicit default is given, and there's no _foo_default method, then the default for a.foo is None despite the allow_none=False.

The two problems are largely orthogonal, so perhaps this should be two issues.

For the first issue, one possible fix we might consider would be to introduce a trait type factory class StrictInstance, something like (with code stolen from @corranwebster):

def StrictInstance(klass, factory=None, args=(), kwargs={}, **metadata):
    return Instance(
        klass=klass,
        factory=factory,
        args=args,
        kwargs=kwargs,
        allow_none=False,
        **metadata,
    )

Then the type hints for StrictInstance can communicate that StrictInstance(SomeClass) always stores a non-None value.

For the second issue, in almost all cases in practice the intended meaning of allow_none=False ought to be "the value of this trait is never None"; we could consider changing the behaviour so that accessing the trait value before setting it raised an exception instead of producing None. This would likely break existing code, so would need to be done carefully, and likely only in a major release.

@mdickinson
Copy link
Member Author

See also #1662.

@corranwebster
Copy link
Contributor

I haven't played with this, but one other possibility is that there may be some solution using a TypeGuard.

@mdickinson mdickinson added type: enhancement component: typing stubs Issues related to the mypy typing stub files component: core Issues related to the core library labels Aug 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: core Issues related to the core library component: typing stubs Issues related to the mypy typing stub files type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants