Consolidate typing for coords with Coords and StrongCoords aliases (fixes #7972)

[aman-coder03]

this PR addresses issue #7972 by consolidating the typing of coords across the PyMC codebase.

Previously, coords appeared with a mix of types such as:

• Sequence
• Sequence | np.ndarray
• dict[str, Any]

this PR introduces explicit and consistent type aliases:

• CoordValue
• Coords
• StrongCoordValue
• StrongCoords

(similar to the existing Shape, Dims, and StrongDims aliases in shape_utils)

Key changes

• standardizes Model.coords to return StrongCoords
• updates ArviZ conversion to return StrongCoords instead of dict[str, Any}
• removes the mixed use of Sequence, Sequence | np.ndarray, and untyped dictionaries
• improves static typing and downstream library compatibility

Notes

while testing this change, a runtime circular import involving:
pymc.model.core
pymc.distributions.shape_utils
from pymc.model import modelcontext
pymc.model (partially initialized)
was encountered.

Fixes #7972

[ricardoV94]

Why this functional change? Doesn't seem necessary or a good idea

[aman-coder03]

i introduced the lazy import only to work around the circular import that surfaced during the typing consolidation (shape_utils -> model -> distributions -> shape_utils). I agree that changing runtime behavior here is not ideal
if you prefer, i can revert this functional change and instead resolve the circular dependency purely by relocating the typing aliases to a more independent module

[ricardoV94]

Put these in a more independent place to avoid the new circular import issues. Coordinates are not really distribution specific anyway

[aman-coder03]

i can move CoordValue, Coords, StrongCoordValue, and StrongCoords to a more independent location and update downstream imports accordingly. Let me know if you have a preferred target module for these.

[aman-coder03]

@ricardoV94 it would be really helpful if you could review the changes!

[ricardoV94]

I'll ping some folks who are bigger fans of type-hints than me for review.

A whole new file seems a bit cluttering, although it could be useful to move more things in the future. My gut feeling would be to just throw this into one of the utils.py files for now.

[aman-coder03]

@ricardoV94 Thanks for the feedback!! I have implemented the changes!!

[williambdean]

Thoughts on a pymc.typing module?

from pymc.typing import Coords
import pymc as pm


coords: Coords = {"covariate": ["A", "B", "C"]}
model = pm.Model(coords=coords)

Or directly from pm

Seems out of place in the utils module.

[ricardoV94]

What would go in it? If it's just a handful doesn't seem worth it

[codecov]

Codecov Report

❌ Patch coverage is 97.95918% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 91.50%. Comparing base (87f80f9) to head (27b010d).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
pymc/distributions/shape_utils.py	93.33%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7987   +/-   ##
=======================================
  Coverage   91.49%   91.50%           
=======================================
  Files         116      116           
  Lines       18963    18992   +29     
=======================================
+ Hits        17350    17378   +28     
- Misses       1613     1614    +1     

Files with missing lines	Coverage Δ
pymc/backends/arviz.py	96.09% <100.00%> (+0.04%)	⬆️
pymc/model/core.py	93.30% <100.00%> (ø)
pymc/printing.py	87.66% <100.00%> (+0.16%)	⬆️
pymc/step_methods/state.py	95.52% <100.00%> (ø)
pymc/util.py	82.18% <100.00%> (+1.07%)	⬆️
pymc/distributions/shape_utils.py	91.41% <93.33%> (-0.47%)	⬇️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[aman-coder03]

Thanks for the feedback! @ricardoV94 @williambdean

Right now it’s just the coord/shape aliases (Coords, CoordValue, StrongCoords, etc.).
So I agree it might feel too small to justify a standalone pymc.typing module at the moment.

Reason for grouping them was:
They do not really fit semantically into util.py
They are used across several modules (model, backends, shape_utils)
A dedicated namespace keeps things cleaner as more typing-related additions come in later

But I'm also happy to keep everything inside pymc.util
Let me know which direction you would like, and I will update the PR accordingly.