Entities are defined dynamically via Config.load() from JSON files, which works well internally, but means:
- valid keys are only known at runtime
- they are not statically inferable (no autocomplete / type checking)
- it’s easy to make mistakes (e.g. confusing whether to use the entity name or its abbreviation in filenames/patterns, which form should be used)
Proposal
It would be helpful to expose the valid keys more explicitly, for example by providing a Literal[...] type of accepted keys:
from typing import Literal
type BIDSEntityNames = Literal["subject", "session", ..., "suffix", "extension"]
type DerivativeEntityNames = Literal[...]
To keep this in sync with the JSON config, a simple test could ensure consistency between the values in the config and the declared types.
This might help make the use of entities bit clearer in the public API, and improve the overall developer experience (especially for IDE support and fewer “guessing games” when using filter keys).
Please let me know if i missed something obvious here!
I know that adding types to the function parameters would mean that new entities from custom configs could not be respected.
Entities are defined dynamically via
Config.load()from JSON files, which works well internally, but means:Proposal
It would be helpful to expose the valid keys more explicitly, for example by providing a
Literal[...]type of accepted keys:To keep this in sync with the JSON config, a simple test could ensure consistency between the values in the config and the declared types.
This might help make the use of entities bit clearer in the public API, and improve the overall developer experience (especially for IDE support and fewer “guessing games” when using filter keys).
Please let me know if i missed something obvious here!
I know that adding types to the function parameters would mean that new entities from custom configs could not be respected.