STYLE: Use itk.int64_t and itk.uint64_t instead of if os.name == "nt"

[N-Dekker]

Replaced if os.name == "nt" statements which used itk.SL, itk.SLL, itk.UL, or itk.ULL with the equivalent code, using just itk.int64_t or itk.uint64_t.

Aims to improve code readability and remove OS-specific code.

• Follow-up to pull request ENH: Add ctype aliases for numeric types of specific sizes to Python #6762 commit dc0ea28

[hjmjohnson]

Thanks! I think this is much cleaner.

[N-Dekker]

Does anyone here know, is this a similar case?

ITK/Modules/Core/Mesh/wrapping/test/itkMeshArrayPixelTypeTest.py

Lines 30 to 34 in f1daa03

	# For windows use itk.ULL
	if hasattr(itk.VectorContainer, "ULAD"):
	IdentifierType = itk.UL
	else:
	IdentifierType = itk.ULL

What is the meaning of "ULAD"? And then, is if hasattr(itk.VectorContainer, "ULAD") equivalent to if os.name == "nt"? Would it allow replacing these five lines with a simple IdentifierType = itk.uint64_t as well?

(It's not a show-stopper to me, I'm just wondering... 🤔)

[dzenanz]

is if hasattr(itk.VectorContainer, "ULAD") equivalent to if os.name == "nt"

Probably, but I am not entirely sure. PR good even as-is.

[N-Dekker]

Probably, but I am not entirely sure. PR good even as-is.

Thanks @dzenanz I see now, the "ULAD check" was introduced by Pranjal (@PranjalSahu) PR #2970 commit 7e59d1b, merged on Dec 17, 2021. You already commented at #2970 (comment)

A generic way to check for Windows is if os.name == 'nt'. But if the one you wrote here works, we should keep it.

On my Windows 11 laptop, os.name == 'nt' is true, and hasattr(itk.VectorContainer, "ULAD") is false👍

---

So in practice, I think hasattr(itk.VectorContainer, "ULAD") is equal to os.name != 'nt' 😃

[greptile-apps]

Greptile Summary

This change replaces platform-name branching with ITK fixed-width integer aliases in Python wrapper support and serialization tests. A parent-versus-update compatibility check exercised NumPy uint64 mapping, vector-container index selection, and the ST, IT, and OT aliases under simulated POSIX and Windows wrapper conventions. The check produced identical 64-bit type selections before and after the change, disproving a regression in those paths. No defects were found.

Confidence Score: 5/5

Safe to merge based on the exercised compatibility paths: the updated aliases preserve the previous 64-bit wrapper behavior on both simulated platform conventions.

The focused parent-versus-update check passed for every changed type-selection path and found no publishable defect.

Files Needing Attention: No files need follow-up attention.

T-Rex Logs

What T-Rex did

• Ran the uint64 alias compatibility check scripts for HEAD^ and HEAD to validate cross-version 64-bit alias handling.
• The harness loaded the parent and head definitions with minimal ITK and NumPy stubs and exercised NumPy uint64 mapping, vector-container binding selection, and the ST/IT/OT aliases under simulated POSIX and Windows conventions.
• The combined parent-versus-head run produced PASS parent_and_head_match_for_all_claimed_paths and exit code 0, with both revisions selecting the same 64-bit types.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "STYLE: Use itk.int64_t and itk.uint64_t ..." | Re-trigger Greptile}

[dzenanz]

It is up to you whether you also want to update the "ULAD check".