Re:Python’s “type hints” are a bit of a disappointment to me
by icedchai on Friday April 22, 2022 @08:40PM
(#31130095)
The problem with these sorts of "rules" is they create needless changes outside of the PR's primary focus. The PR's purpose is to do X: add a feature, fix a bug, whatever. Now because I've done X, you want me to do Y, a set of totally unrelated changes that ultimately are a distraction.
Re:Python’s “type hints” are a bit of a disappointment to me
by ok_dad on Saturday April 23, 2022 @05:49AM
(#31132742)
Why wouldn’t you submit two different branches to review? One where you fix errors for types and another for the feature with the fixes:
(git main) > git checkout -b abc-1234/type-fixes
<do work on types and commit it>
(git abc-1234/type-fixes) > git checkout -b abc-1234/feature-branch
<do work on feature and commit it>
Then you can submit the feature branch as a PR on top of the type fixing branch and a PR for that branch to main. You only see the type fixing changes on that PR and only see the feature changes on its PR.
I did occasionally get pushback on it but stricter checks will be inconvenience at first and I argued it’d help over time. Now that we’ve had it a year it’s pretty well accepted in same way many would accept run formatter.