Handle F401 exclusions more granularly

[Repiteo]

Was originally going to be a separate stylistic dive, but this discrepancy caught my eye so I wanted to handle it now. This removes the per-file exclusions of F401, instead handling them on a per-include basis. Also removed the exclusion from test files, as those are already explicitly setup to NOT get checked by Ruff

Contributor Checklist:

• I have created a new test or updated the unit tests to cover the new/changed functionality.
• I have updated CHANGES.txt and RELEASE.txt (and read the README.rst).
• I have updated the appropriate documentation

[mwichmann]

For Util, the correct answer is probably to add things that are "module global" to __all__. I didn't do that when I split the one giant file into a package three years ago (d83d7cf)

[mwichmann]

Finally had a chance to go through this with some attention, LGTM.

[Repiteo]

For Util, the correct answer is probably to add things that are "module global" to __all__. I didn't do that when I split the one giant file into a package three years ago (d83d7cf)

While that might be technically correct, I'd rather not "codefy" backwards-compatibility includes. If anything, I'd like to start implementing our own equivalent of the 3.13 @deprecated annotation¹ to help nudge users to more modern conventionsm, but that's obviously out of the scope for this PR

Footnotes

1. https://docs.python.org/3/library/warnings.html#warnings.deprecated ↩

[mwichmann]

While that might be technically correct, I'd rather not "codefy" backwards-compatibility includes. If anything, I'd like to start implementing our own equivalent of the 3.13 @deprecated annotation to help nudge users to more modern conventionsm, but that's obviously out of the scope for this PR

Yeah, thought about a decorator several times in the past. The one that appeared in 3.13 has a "backport" in typing_extensions, which I guess is where it came from originally.

[bdbaddog]

For Util, the correct answer is probably to add things that are "module global" to __all__. I didn't do that when I split the one giant file into a package three years ago (d83d7cf)

While that might be technically correct, I'd rather not "codefy" backwards-compatibility includes. If anything, I'd like to start implementing our own equivalent of the 3.13 @deprecated annotation1 to help nudge users to more modern conventionsm, but that's obviously out of the scope for this PR

Footnotes

1. https://docs.python.org/3/library/warnings.html#warnings.deprecated [↩](#user-content-fnref-1-b8dab9f640942eb2be1d08e1aaacf847)

I don't think we'd want to do that.
We explicitly choose which python versions to support so as long as a user is using a support version nagging them with deprecation warnings wouldn't be scons'ian..
When we deprecate a version (coming soon btw), we have mechanisms in SCons already to deprecate python versions with warnings when they run SCons.

[bdbaddog]

Please don't force push. If we're commenting and you're changing we lose that history it's a hassle.