Should Arg required priority be higher than default?

[wu-clan]

When both default and required=False are set, the default value is always returned, should None be returned instead of the default?

Perhaps, when we add required=False, we should delay evaluating the default value and parameter unless the parameter is explicitly used, and then the default value is returned.

[DanCardin]

I'm not sure i understand the question/problem. A minimal example of a cli and the situations in which you'd expect a specific value or not would be very helpful.

Setting a default implies required=False automatically. required-ness only affects whether the parser will fail/provide a user error in the absence of a corresponding argument. So if a user is not providing a value for the situation you're describing, i dont see how we can safely do anything other than fail or return the default value.

Based on your other issue, i wonder if this is relating to a more complex/dynamic default and you're perhaps looking for default value fallbacks?

[wu-clan]

Here is an MRE:

from dataclasses import dataclass
from typing import Annotated

import cappa


@dataclass
class Test:
    num1: Annotated[int, cappa.Arg(default=1, required=False)]
    num2: Annotated[int | None, cappa.Arg(default=2, required=False)]

    def __call__(self):
        if self.num1:
            print(self.num1)
        if self.num2:
            print(self.num2)


cappa.invoke(Test)

By default, python t.py outputs:

1
2

In my opinion, we should defer the evaluation of num2, as it's type allows it to be null, and due to the explicit required=False, it should not default to output 2 unless the user explicitly provides the parameter.

python t.py will output:

1

python t.py 1 2 will output:

1
2

Here is another scenario:

num2: Annotated[int | None, cappa.Arg(default=2, required=False)] = None

By default, num2 always returns empty/None. This seems to align with what I described above, but I'm not sure if this is an issue or expected.

[pawamoy]

In my opinion, we should defer the evaluation of num2, as it's type allows it to be null, and due to the explicit required=False, it should not default to output 2 unless the user explicitly provides the parameter.

I disagree. If you tell Cappa to use a default value, this value should be used when one isn't provided. The None value can still be obtained by building your Test dataclass programmatically (not passing through Cappa's system).

python t.py 1 2 will output: 1 2

Just to be sure, python t.py 1 3 would output 1 3, right? Then, what's the point of the default value? I don't see when it would be used here.

[DanCardin]

Yea i'm not sure what purpose default=2 has in your original example, particularly if you're looking for None. Why would you not be setting the default to None versus 2 here?

On "Optional" types we do infer None as a default (by default) if you have no explicit default provided, but any provided default is meant to imply that the user doesn't want that behavior and chooses their own.

For num2: Annotated[int | None, cappa.Arg(default=2, required=False)] = None defaulting to None, this seems more like a bug. i'd consider any explicit values provided to cappa machinery (e.g. Arg) to have higher precedence than more generic sources of information like the dataclass-level default/default_factory. That way, if you used the class programmatically outside the context of cappa, you could theoretically have a different class-level default from what you wanted cappa, in particular, to use.

[wu-clan]

On "Optional" types we do infer None as a default (by default) if you have no explicit default provided, but any provided default is meant to imply that the user doesn't want that behavior and chooses their own.

I completely agree that default is the user‘s default input in a sense.

[DanCardin]

fwiw #241 to correct the fact that foo: Annotated[int, Arg(default=5)] = 10 should produce 5, not 10.