Python’s “type hints” are a bit of a disappointment to me

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

Re:Python’s “type hints” are a bit of a disappointment to me by icedchai on Saturday April 23, 2022 @09:33AM (#31134110)

Seems fine to me, but in my experience these “rules” are often tied to a single PR and various automated CI checks.

[ Parent | on HN ]