mypy compliance

[liamhuber]

At the last meeting of December, @niklassiemer indicated he was fine learning whatever typing stuff was necessary in the event he takes over maintenance, so this PR is intended to close #514.

My current plan is to take any low-hanging fruit (e.g. hinting typing.Callable instead of callable) and just commit it directly here, but to break larger changes into stacked PRs so it's easier to view the diff and see intentions. I started using a file-based approach and have a branch for getting the channels sub-module compliant, but for things in the mixins it may make more sense to group the PRs so they touch multiple files, but updating a single root class.

@niklassiemer, you may want to keep an eye on this series of PRs just to get a rough sense of what was involved in this transition.

@XzzX, I'll ping you for review on this root branch when I feel it's done, but I'll freely merge the feature/file branches into it without delay. Nonetheless, feel free to also keep an eye on the whole series of PRs and interject whenever you have insight, and/or just stack fixes you want right on top of here.

EDIT: as long as it's in draft state, I'm not going to sweat about ruff and black failures. Definitely before merging, and I'll try to patch them up when I get a chance, but I am going to prioritize avoiding merge conflicts with any stacked branches over keeping the formatters permanently happy.

Progress tracker: mypy complaints

• Initial push) 161
• mypy channels #534) 148
• mypy channels redux #536 and Apply hints to IO panels #537) 126
• mypy run #541) 119
• mypy topology and find #542) 114
• mypy semantics #538) 106
• Semantics generic parent #544) 102
• Improvements to semantic labeling #547) 101
• Annotate some extra returns #548) 100
• Make the HasChannel interface generic on the Channel type #550) 99
• Generic HasIO classes to specify data output panel types #551) 84
• More return hints #552) 81
• mypy storage #553) 63
• mypy signature compliance #554) 56
• mypy draw #555) 52
• Generic value receiver #556) 51
• on-branch trivialities) 33
• Change return on Composite.remove_child #558) 32
• IO maps #559) 31
• on-branch trivialities) 30
• Return both nodes on replacement #560) 28
• on-branch trivialities) 16
• mypy for_loop #561) 8
• mypy finishing touches #562) 0

[github-actions]

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

[liamhuber]

Windows tests failed, but CondaHTTPError: HTTP 000 CONNECTION FAILED for url <https://conda.anaconda.org/conda-forge/noarch/repodata.json>, so hopefully it is just a hiccup.

EDIT: Yep. Better now.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ -0.09% (target: -1.00%)	✅ 95.66%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (53a5c14)	3356	3070	91.48%
Head commit (e36409b)	3425 (+69)	3130 (+60)	91.39% (-0.09%)

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 (#533)	415	397	95.66%

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}

[coveralls]

Pull Request Test Coverage Report for Build 12839449964

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 200 unchanged lines in 23 files lost coverage.
• Overall coverage decreased (-0.09%) to 91.387%

---

Files with Coverage Reduction	New Missed Lines	%
nodes/function.py	1	98.41%
type_hinting.py	1	97.78%
nodes/transform.py	2	98.24%
mixin/single_output.py	2	97.53%
nodes/for_loop.py	2	98.21%
mixin/has_interface_mixins.py	3	90.0%
find.py	3	90.32%
storage.py	4	95.37%
topology.py	5	88.61%
mixin/injection.py	6	95.28%

Totals
Change from base Build 12778163625:	-0.09%
Covered Lines:	3130
Relevant Lines:	3425

---

💛 - Coveralls

[liamhuber]

I currently only point mypy at the main module; I'd like to make the tests compliant as well, but that can be done at a later time in a separate PR.

[XzzX]

I hope I got the idea of the channels, right.

[XzzX]

@XzzX, I'll ping you for review on this root branch when I feel it's done, but I'll freely merge the feature/file branches into it without delay. Nonetheless, feel free to also keep an eye on the whole series of PRs and interject whenever you have insight, and/or just stack fixes you want right on top of here.

I favor smaller piece to review. I do not think I will be able to do a review of the final branch. But I can have a look at the smaller pieces if you want.

[liamhuber]

@XzzX, I'll ping you for review on this root branch when I feel it's done, but I'll freely merge the feature/file branches into it without delay. Nonetheless, feel free to also keep an eye on the whole series of PRs and interject whenever you have insight, and/or just stack fixes you want right on top of here.

I favor smaller piece to review. I do not think I will be able to do a review of the final branch. But I can have a look at the smaller pieces if you want.

Yes, that's fair. Ok, so then we'll modify slightly: I'll ping you for review on each of the smaller stacked PRs instead and you're free to review them (or not) at your leisure. I'll leave them open for as long as I can, but if I'm worried about merge conflicts before you have a chance to get to it, I'll still just merge them down. You can nonetheless provide feedback on them post-merge, and we can simply slap on patching branches when it's convenient, ala #535.