How strict is type checking for input/output?

[XzzX]

How strict is the type checking for input/output?
Can I provide an int output for a float input?
Can I provide a float output for a np.float64 input?

[liamhuber]

Can I provide an int output for a float input?

No, because these are different types.

Can I provide a float output for a np.float64 input?

Yes, because issubclass(np.float, float).

These are both super simple cases you can just set up and check and see.

How strict is the type checking for input/output?

The idea is simply that the type of the incoming value or connection should be "as or more specific than" the hint on the receiving channel, hence pyiron_workflow.type_hinting.type_hint_is_as_or_more_specific_than. The heart of this is just

try:
    return issubclass(hint, other)
except TypeError:
    return hint == other

The function is 60 lines instead of just those 4 lines in order to handle all the combinations of hinted/unhinted, and to try and deal with composite hints (e.g. list[tuple[int, str]]). I haven't gone in and refactored it in forever, it could probably be tightened up.

To be honest, I can't guarantee it is totally robust -- I'm using proof by lack of imagination in that it hasn't failed me yet.

[XzzX]

I am asking to get a clearer picture on how accurate we have to be during save/load if the underlying file format looses the exact type.

[liamhuber]

If you want to save/load workflow instances, I believe losing the types of stuff is simply going to break things