I just removed the adding of prospector: ignore=...
Note that the current prospector implementation of noqa interferes with ruff because with Ruff, it's possible to ignore a list of code, and the prospector implementation will ignore all the errors!
https://docs.astral.sh/ruff/linter/#error-suppression

And I create in issue for the rest of the code: #715 :-)

With the current code, I didn't introduce anything except the possibility to disable the prospector # noqa and the #pyflake: noqa that can have bad interaction with, e.g. Ruff.
For example, I add # noqa: F841 to disable only one Ruff rule, and it disables all the rules including Bandit.

In my code, I don't like to ignore all the issues with won comment because with that, we don't know what's ignored,
we don't know if new code introduces a new issue on the same line.

Finally, we can prefer to have the control with a long line or just ignore anything that we don't know with a short line.
It's a chose and I don't know that Prospector should do this chose for you :-)

For example, I add # noqa: F841 to disable only one Ruff rule, and it disables all the rules including Bandit.

This is pretty bad, but shouldn't it be fixed in bandit ?

Fix in bandit that Prospector hide his issue?

With the current code at least we have # noqa on a line of the code Prospector will filter all the issues on this line, it's a Prospector issue not a Bandit one!

I'm not quite following here, so please correct me.

Is the problem that disabling a message for ruff will disable the equivalent message from other tools? If so that's intended behaviour of the "blender" which tries to remove duplicate warnings. This can be disabled with the --no-blending flag or config.

Or is the problem that #noqa: F123 is incorrectly being applied to all messages from other tools, rather than a specific one? So while you might have pylint: disable=F123 the #noqa: F123 is being incorrectly used by prospector as a generic #noqa? In which case it sounds like better parsing/processing of prospector is necessary more than new features.

Or what am I missing?

Hello @carlio it's the second, I can work on a better implementation or # noqa... :-)

My bad I misunderstood what you were saying.

No problème @Pierre-Sassoulas :-)