I tried to fix the error in a few places, by various mechanisms, but there is a common source for this: the raise_error function.
Unfortunately, Pylint is not being able to detect that the raise_error function is just raising an error, and so the respective branches in the various ifs will never return.
I tried to tell it through the typing.NoReturn hint (better called Never, but only from py3.11 on...), but it didn't work.
The simple option is to keep applying fixes like the one showcased here for the few missing cases, and just upgrade Pylint.
The other two, more drastic, options are:
give up on raise_error, and just stick to the built-in raise
Both of them are feasible, but both of them would require non-negligible effort (the first is spread throughout the whole codebase, and dependent packages - though we are already considering removing in other places because of #1117 - and the second requires workflows upgrades, and possibly further lints to fix).
With Pylint 3.2 the E0606 error is being raised in a few places, i.e.:
As it was found in https://github.com/qiboteam/qibo/pull/1282#discussion_r1601976588. The current solution has been to block Pylint updates, but this is not great.
I tried to fix the error in a few places, by various mechanisms, but there is a common source for this: the
raise_error
function.Unfortunately, Pylint is not being able to detect that the
raise_error
function is just raising an error, and so the respective branches in the variousif
s will never return. I tried to tell it through thetyping.NoReturn
hint (better calledNever
, but only from py3.11 on...), but it didn't work.The simple option is to keep applying fixes like the one showcased here for the few missing cases, and just upgrade Pylint. The other two, more drastic, options are:
raise_error
, and just stick to the built-inraise
ruff
Both of them are feasible, but both of them would require non-negligible effort (the first is spread throughout the whole codebase, and dependent packages - though we are already considering removing in other places because of #1117 - and the second requires workflows upgrades, and possibly further lints to fix).