Specify input/output fields with dictionaries instead of tuple/dict hybrid

[tclose]

My 2 cents on a minor stylistic issue, but I feel like it might be more intuitive if fields in shell-command input/output specs were defined with dictionaries rather than tuples including dictionaries for metadata, e.g.

Instead of

input_fields = [
    (
        "in_dir",
        Directory,
        {
            "argstr": "'{in_dir}'",
            "position": -1,
            "help_string": ("The directory containing the DICOMs to be converted"),
            "mandatory": True,
        },
    ),
    (
        "out_dir",
        Directory,
        {
            "argstr": "-o '{out_dir}'",
            "help_string": "output directory",
            "mandatory": True,
        },
    ),
    (
        "filename",
        str,
        "out_file",
        {"argstr": "-f '{filename}'",
         "help_string": "The output name for the file"},
    ),
...

each field in the field specification is stated explicitly

input_fields = [
    {
        "name": "in_dir",
        "type": Directory,
        "argstr": "'{in_dir}'",
        "position": -1,
        "help_string": ("The directory containing the DICOMs to be converted"),
        "mandatory": True,
    },
    {
        "name": "out_dir",
        "type": Directory,
        "argstr": "-o '{out_dir}'",
        "help_string": "output directory",
        "mandatory": True,
    },
    {
        "name": "filename",
        "type": str,
        "default": "out_file",
        "argstr": "-f '{filename}'",
        "help_string": "The output name for the file"
    },
...

IMO it would make the specs more amenable to JSON/YAML formats. Sorry if this has been debated before

[ghisvail]

I believe a proper record type would provide stronger type safety than a plain dictionary. JSON / YAML (de)serialization can be derived from it (cattr provides it for attr or dataclass based record types for instance).

I agree with Tom that the current approach using unnamed tuples is not the most straightforward to write from an interface writer perspective.