Open corranwebster opened 5 months ago
A note that allowing the possibility of forward declarations with strings causes problems with inference in complex types. For example:
Dict(Instance(Foo), Instance(Bar))
can't be resolved as Dict[Foo, Bar, Foo, Bar]
because the possibility of forward definitions can leave the type unclear even though we aren't using forward references.
This can be resolved by:
Dict(Instance[Foo](Foo), Instance[Bar](Bar))
but it is sort of awkward.
The definition of
BaseInstance
intrait_types.pyi
looks like this: https://github.com/enthought/traits/blob/9778f4df710aaccf2a6680d3ce485fab2c196694/traits/trait_types.pyi#L512-L521I think that this should read:
since we're passing in a type or a
str
to the__init__
function (ignoring the corner case that Traits will acceptInstance(foo)
to meanInstance(type(foo))
since that is almost never used in declarative code), but the values are instances of the type or None (and never a string unless you doInstance(str)
, so the_TraitType[_Union[_T, str, None], [_Union[_T, str, None]]
is wrong).We have to allow
str
since that is a valid argument needed for forward definitions, but they leave the actual type unspecified; in those cases you can potentially explicitly define the type with a type declaration something like:which should at least work for classes defined in the same module, or
for lazy instances.
In current code, this all gets plastered over because we then force
_T
to beAny
in the concrete definition, but it means that tools like mypy can't infer the type from the definition so you are forced to do a lot ofisinstance
checks.This is orthogonal to #1673 and solving this won't solve that.