Original PR (#29389) has been backported to 3.9 and 3.10 so I'll backport this to 3.9 and 3.10 too.

Original PR (#29389) has been backported to 3.9 and 3.10 so I'll backport this to 3.9 and 3.10 too.

I think@ambv already applied this to 3.9/3.10:

• dc23aed
• 0111c5a

(Sorry for the bother — thanks for fixing!)

@JulienPalard, since we're no longer runningmake suspicious in CI formain per your own change (GH-26575), should we just stop caring aboutmake suspicious at all?

@JulienPalard, since we're no longer runningmake suspicious in CI formain per your own change (GH-26575), should we just stop caring aboutmake suspicious at all?

Soon, yes. The idea is I'm tracking closelymake suspicious inbpo-42238 to see if there's true positives that I can implement inrstlint.py. It allowed me to add a few new things in rstlint:

• bda69ab
• fbf1008
• 01331f1
• b973542

and we do ensure rstlint in the CI as it make no false positives.

So « soon » rstlint should catch all the true positives of make suspicious, leaving only false positives formake suspicious.

This day I'll just drop it, and really stop caring about it.

Up to this day I prefer having an up-to-datesusp-ignored.csv, so I can easily monitor new alerts.

(But I only watch master so backporting can be ignored, yes)

and we do ensure rstlint in the CI as it make no false positives.

Arguably rstlintdid have a few false positives in this PR 🙂 (but maybe I'm just too backtick-happy!)

Arguably rstlintdid have a few false positives in this PR slightly_smiling_face (but maybe I'm just too backtick-happy!)

This is a really interesting information, TIL, thanks! I'll have to look at it :D