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.

[Repiteo]

When we deprecate a version (coming soon btw), we have mechanisms in SCons already to deprecate python versions with warnings when they run SCons.

We indeed have mechanisms for deprecating Python versions, but what I hope for is a means of deprecating functions/accessors based on SCons version. We probably couldn't use a 1-1 port of Python's @deprecated anyway, as we'd still want to let users opt-out of nagging warnings

[bdbaddog]

When we deprecate a version (coming soon btw), we have mechanisms in SCons already to deprecate python versions with warnings when they run SCons.

We indeed have mechanisms for deprecating Python versions, but what I hope for is a means of deprecating functions/accessors based on SCons version. We probably couldn't use a 1-1 port of Python's @deprecated anyway, as we'd still want to let users opt-out of nagging warnings

What would that look like? We have EnsureSConsVersion()
Anything more than that doesn't make sense to me.. Perhaps I'm missing something

EnsureSConsVersion(major, minor, [revision])
Ensure that the SCons version is at least major.minor, or major.minor.revision. if revision is specified. This function will print out an error message and exit SCons with a non-zero exit code if the actual SCons version is not late enough.

Examples:

EnsureSConsVersion(0,14)

EnsureSConsVersion(0,96,90)

[mwichmann]

can we move deprecations somewhere else? it's an interesting topic as there are almost three layers to it, but shouldn't get in the way of this simple PR.