STYLE: Standardize Python shebangs on env python3

[hjmjohnson]

Backport of #6842. Standardizes Python shebangs on #!/usr/bin/env python3: 19 from env python, 2 from /usr/bin/python, one bare #!python, and one #!/bin/env python. One commit per shebang class.

Independent of the removal backport — no shared files, and the two merge cleanly in either order (verified both directions).

Why python3 rather than python

PEP 394 does not guarantee that a python command exists at all. Debian and Ubuntu ship none by default, and RHEL 8+ places it behind alternatives, so #!/usr/bin/env python is a coin flip on a current machine while python3 resolves wherever Python 3 is installed.

A hardcoded #!/usr/bin/python is worse on both counts: it bypasses virtual environments and conda prefixes entirely, and on current systems that path is either Python 3 or absent — so the shebang no longer means what it said when it was written.

Windows is not a counterargument. The py launcher (PEP 397) resolves #!/usr/bin/env python3 to the latest installed Python 3, so python3 is at least as portable there as python.

Verification that every touched script is Python 3

All 23 files:

• parse under Python 3 (ast.parse, 0 syntax errors) — also covered by the check-ast hook;
• contain no Python 2 runtime idioms. Scanned for .iteritems(), .itervalues(), .iterkeys(), xrange(), raw_input(), basestring, urllib2, ConfigParser, .has_key() — no matches.

The only two scripts in the tree that are Python 2 (StripIncludes.py uses .iteritems(), ParallelStripIncludes.py uses xrange()) are deliberately excluded here; they are removed in the companion backport rather than given a python3 shebang that would convert a silent failure into a runtime crash.

Better long-term alternatives to shebang maintenance

Hand-maintained shebangs drift, which is how #!python and #!/bin/env python survived on release-5.4 for years. Options that remove the class of problem rather than fixing instances:

• Stop relying on direct execution. Most of these scripts are invoked as python3 script.py from documentation or CI. A script that is never executed directly does not need a shebang or an executable bit, and dropping both makes the intent explicit.
• Package the ones that are real entry points. A [project.scripts] entry in pyproject.toml generates a correct launcher per platform, including Windows .exe shims, and removes the question entirely.
• Let tooling enforce it. check-shebang-scripts-are-executable (already enabled here) catches the mismatch between shebang and mode but not an unresolvable interpreter. Ruff's EXE rules do check the interpreter itself — EXE003 flags a shebang that does not name python, and EXE001/EXE002 cover the mode pairing on POSIX and Windows.

Ruff is not currently a dependency on either branch — the Python hooks are black and pyupgrade — so an EXE gate would mean adding a hook repo, not toggling a setting. That is a separate change and is not proposed here.

The bare #!python here is the finding Greptile raised on #6840; main already carries a resolvable shebang for that file.

[greptile-apps]

Greptile Summary

Summary

• Corrects the executable declaration in Utilities/Maintenance/VNL_ModernizeNaming.py to select Python 3 from the active environment.
• Direct execution succeeds with a Python-3-only environment and performs the expected vnl_math_abs to itk::Math::abs transformation on a temporary input.

Merge safety

Safe to merge.

Confidence Score: 5/5

The updated interpreter declaration was directly exercised successfully and no regressions were identified.

There are no actionable findings.

Files Needing Attention: None.

T-Rex Logs

What T-Rex did

• T-Rex ran the requested verification for the pull request.
• T-Rex observed that local artifact references were not uploaded during the verification run.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "STYLE: Correct the VNL_ModernizeNaming.p..." | Re-trigger Greptile}