Removing lint rule use-implicit-booleaness-not-comparison and updates

[joesho112358]

Summary

#9614 test for removing use-implicit-booleaness-not-comparison

Details and comments

Only 2 hits came from this locally. Looks like it might be a misnomer in that you can use comparison checks if the variable is not defined directly... maybe? Jetbrains still flagged it.

Flagged:

    sta.append([cnots, range_list, epsilon])
    while sta != []:

Not flagged:

        [cnots, ilist, qubit] = sta.pop()
        if cnots == []:

[coveralls]

Pull Request Test Coverage Report for Build 8851495034

Details

• 2 of 2 (100.0%) changed or added relevant lines in 2 files are covered.
• 6 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.007%) to 89.436%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/lex.rs	6	92.37%

Totals
Change from base Build 8851171785:	0.007%
Covered Lines:	60925
Relevant Lines:	68121

---

💛 - Coveralls

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the the following people are requested to review this:

• @Qiskit/terra-core
• @nkanazawa1989

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the the following people are requested to review this:

• @Qiskit/terra-core
• @nkanazawa1989

[levbishop]

I'm surprised the type inference is good enough (conservative enough?) to only flag these two cases, which are clearly safe since the variables in question can only be tuple/list. Still a bit nervous to turn on this lint though. Will wait for comments from others.

[joesho112358]

I'm surprised the type inference is good enough (conservative enough?) to only flag these two cases, which are clearly safe since the variables in question can only be tuple/list. Still a bit nervous to turn on this lint though. Will wait for comments from others.

I don't mind shutting this one down and moving it to the permanent lint area, but i figured the lift was small enough I would just remove it and throw it out there!

[jakelishman]

For the hits/no-hits: possibly pylint is being conservative and only suggesting the lint if it can confidently narrow the type to be purely a sequence type. Resolving the type of l = []; l.append((a, b, c)); l.pop()[0] is rather harder than a lot of other things, because the line l = [] produces only a partial type (List[?], say) that needs to be filled in later, and the calls to append all need to be fully inferred too.

This definitely isn't my favourite lint rule, but given the minimal changeset, I feel ok turning it on with a view that we can turn it off again later if it's a nuisance.

I'll leave this (and the other lint-related PRs) unmerged just for a day or so to make sure they don't accidentally clash with PRs racing to merge for 1.1.0rc1 tomorrow (like we're leaving #12320 til after).