Update tests

[samwaseda]

I updated the type checking because otherwise it fails with annotated typing

[github-actions]

👈 Launch a binder notebook on branch pyiron/pyiron_workflow/extend_type_checking

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.01% (target: -1.00%)	✅ 100.00%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (78bbee5)	3426	3130	91.36%
Head commit (b34d040)	3431 (+5)	3135 (+5)	91.37% (+0.01%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#572)	12	12	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

[liamhuber]

Sorry, I didn't manage to get to this today. Should get it tomorrow.

[liamhuber]

Ok, if you read my commit suggestion and it makes sense and passes the tests, then I've understood this well enough that I've reviewed it and it's approved by me.

But, if you look at that suggestion and you wonder what the heck I was thinking, then either you need to hold my hand or I need to check out the branch and try stuff out, because I've misunderstood. In that case my approval is worth what I've understood -- nothing 😝

[liamhuber]

Is it really intentional to do type(int | float) and not type[int | float] here?

[samwaseda]

What does type[int | float] mean?

[liamhuber]

It is a type hint, that we expect the type int or the type float. In this case bool also works, since it's a subclass of int, but, e.g. string doesn't.

The int | float is generating a typing union, and we're treating type as a generic (i.e. takes subtyoes like list[], so what we've written is shorthand for x: type[int] | type[float].

Concretely, the following runs and mypyp will complain only about foo(str):

def foo(x: type[int, float]) -> None:
    print(x)

foo(int)  # Fine -- in the type hint
foo(bool)  # Fine -- subclass of int
foo(str)  # mypy complains


def equivalent_to_foo(x: type[int] | type[float]) -> None:
    print(x)

type(int | float) is an instance of types.UnionType. Looking at it again, I guess this is actually exactly what you want, since the hint int | float should indeed have a UnionType origin. It's not clear to me whether it matters that you put int | float inside the union type, as I don't know how detailed its == comparison is.

[liamhuber]

Nice, looks like I understood ok. LGTM.