You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Condition comparing incompatible types in "numpy.lib.utils.info" #17490
The condition of this if statement will always be True because it compares a dict and a list with the operator !=. The code of pydoc.allmethods clearly shows that it will always return a dict.
I guess the developer intended to write instead:
if methods != {}:
In case you have any question, suggestion or if you see a False Positive on SonarCloud you can reach out on SonarSource community forum.
A few notes in case you want to use SonarCloud:
I am currently testing the python analyzer so the numpy project I created on SonarCloud will only show python issues, but SonarCloud can also analyze C/C++ code and other languages.
SonarCloud can easily import pylint and flake8 issues in case you want to use a rule SonarCloud does not already provide. Note however that pylint/flake8 rules and SonarCloud rules are implemented differently. You might see new issues with SonarCloud, or less issues in some cases (we try to avoid False Positives as much as possible).
Thanks for the report. This looks valid, but the only effect is that in the np.info function which is probably rarely used, a Methods: heading is printed even if there is no content to print.
A patch would be welcome nonetheless. if methods would probably be the more canonical spelling.
Hey All, I just submitted a PR for this. I know it's a pretty tiny fix, but I love numpy and was looking for a way to get my feet wet with open source. This is my first PR ever!
Excuse me if this is not the right channel for this kind of announcement. I don't know if NumPy mailing list is for NumPy developers or NumPy users.
About two weeks ago I reported a few bugs found in the NumPy repository. This effort was part of a bigger SonarSource Bug Report Campaign. We found some interesting issues in different high-quality projects and we plan to share this result with developers at large in this blog post. Please reach out by the 30th of October if you see anything bothering you.
I don't see anything to bother me there. It only draws attention to #17489, and that's not a security vulnerability and already publically visible anyway. Perhaps @rgommers has an opinion.
Activity
eric-wieser commentedon Oct 7, 2020
Thanks for the report. This looks valid, but the only effect is that in the
np.infofunction which is probably rarely used, aMethods:heading is printed even if there is no content to print.A patch would be welcome nonetheless.
if methodswould probably be the more canonical spelling.MAINT: fix incompatible type comparison in numpy.lib.utils.info.
stevejoachim commentedon Oct 7, 2020
Hey All, I just submitted a PR for this. I know it's a pretty tiny fix, but I love numpy and was looking for a way to get my feet wet with open source. This is my first PR ever!
stevejoachim commentedon Oct 7, 2020
Tried following all the contributing guidelines, but please let me know if I went wrong anywhere.
MAINT: fix incompatible type comparison in numpy.lib.utils.info
MAINT: fix incompatible type comparison in numpy.lib.utils.info
MAINT: fix incompatible type comparison in numpy.lib.utils.info
MAINT: Do not emit empty Methods heading in np.info (#17498)
nicolas-harraudeau-sonarsource commentedon Oct 19, 2020
Hi @eric-wieser,
Excuse me if this is not the right channel for this kind of announcement. I don't know if NumPy mailing list is for NumPy developers or NumPy users.
About two weeks ago I reported a few bugs found in the NumPy repository. This effort was part of a bigger SonarSource Bug Report Campaign. We found some interesting issues in different high-quality projects and we plan to share this result with developers at large in this blog post. Please reach out by the 30th of October if you see anything bothering you.
Kind regards,
Nicolas
eric-wieser commentedon Oct 19, 2020
I don't see anything to bother me there. It only draws attention to #17489, and that's not a security vulnerability and already publically visible anyway. Perhaps @rgommers has an opinion.
rgommers commentedon Oct 19, 2020
Seems fine to me too. Thanks for asking @nicolas-harraudeau-sonarsource
nicolas-harraudeau-sonarsource commentedon Oct 20, 2020
Thank you for your rapid and positive answers @eric-wieser @rgommers!