Literal and case-insensivity?

[pawamoy]

I'm trying to allow both debug and DEBUG as input value of this option:

@dataclass(kw_only=True)
class LogLevelPathOptions:
    """Log level and path options."""

    log_level: An[
        Literal["TRACE", "DEBUG", "INFO", "SUCCESS", "WARNING", "ERROR", "CRITICAL"],
        cappa.Arg(short="-L", long=True, parse=str.upper),
        Doc("Log level to use when logging messages."),
    ] = "INFO"

If I read the docs correctly, Literal implies choices=... which seems to skip my parse callable, resulting in the following error:

pypi-insiders: error: Invalid choice: 'debug' (choose from 'TRACE', 'DEBUG', 'INFO', 'SUCCESS', 'WARNING', 'ERROR', 'CRITICAL')

How would I go about achieving that? Should I store the literal in a type variable and use MyLiteral.__args__ to build the choices? I think it would print both upper and lowercase choices in the help, which wouldn't be great.

[DanCardin]

mm so choices are currently being enforced at the parser level, while all parsing is done after the parsing has already completed.

There is also parsing-level validation of literals, but as a general pattern Arg(parse=...) completely replaces any inference based parsing.

With that said, in this scenario, since it doesn't otherwise affect the parsed value, it's just validation on top of it, I could see where it could make sense to avoid checking choices inside the parser at all, and to only do so at the parsing/mapping phase.

[pawamoy]

I guess you're explicitly disabling completions, but that'd be a reason why choices are relevant to the parser either way. Not that the parser has any specific need to raise versus during the mapping phase.

Sorry, it's unclear from the code I shared, but I declare the completion option myself, to reword its help message, and that's why I'm disabling it the default option in the main invoke call.

I think it should be doable, i'm just struggling to find the right way to formulate it with error handling and sequences of literals and explicit parsers and such.
I anticipate that invalid choice: 'FATAL' is going to be the easier route error-message wise.

That's a fair trade-off, as the valid options are shown in the help message anyway 🙂

[pawamoy]

If you make this change, and I add back choices myself, will my parse callable still work as expected? Because I'm happy to manually provide the choices if they can't be inferred anymore, for error message purposes.

[DanCardin]

Fwiw, you can do completion=Arg(...) to define what the argument should look like.

If this works, I expect the annotation to still imply choices, just non-choice choices wont error inside the parser (and i wont even supply them to argparse, because then it will error). then the mapping will do the check and fail there, so it shouldnt require any changes to the original impl you supplied, i wouldnt think.

[DanCardin]

#179