Remove redundant channel definition

[samwaseda]

It's defined above

[github-actions]

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

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.00% (target: -1.00%)	✅ ∅

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (c33c9e1)	3244	2961	91.28%
Head commit (4e1fb7c)	3243 (-1)	2960 (-1)	91.27% (+0.00%)

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 (#459)	0	0	∅ (not applicable)

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 10939658523

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 4 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.002%) to 91.274%

---

Files with Coverage Reduction	New Missed Lines	%
draw.py	4	92.57%

Totals
Change from base Build 10927133806:	-0.002%
Covered Lines:	2960
Relevant Lines:	3243

---

💛 - Coveralls

[liamhuber]

Rather let's remove the other one -- then we have privates first then publics, which is not some rule but generally more consistent with how I've been writing the rest of the library, and we keep the one with the type hint

[samwaseda]

But isn't it more common to define the types only for the function args?

[liamhuber]

But isn't it more common to define the types only for the function args?

Usually -- crux of the issue is that I'm mis-remembering something. In the following:

class Foo:
    def __init__(self, x: int, y: int):
        self.x = x
        self.y: int = y


f = Foo(0, 1)
f.x = "breaks init hint"
f.y = "breaks class hint"

I thought my IDE would complain about the f.y assignment but let the f.x pass. Turns out it doesn't complain about either 🤦‍♂️

I can still see a space for hinting the attribute directly when the init hint differs from the reality of the attribute, e.g.:

class Bar:
    def __init__(self, x: list | None):
        self.x: list = [1, 2, 3] if x is None else x

[samwaseda]

Yeah I also don't really understand what type hinting inside the function is good for. I guess we can think about it once we figure out what we can do with it.

[liamhuber]

I swear I've seen my IDE respond usefully to it -- probably to an attribute that wasn't in the init signature to start with? But I couldn't reproduce anything in the three minutes I had to play with it