Should `Optional[Tuple[type1]]` be supported about defopt HOT 7 CLOSED

Seems like an oversight, and I would (probably?) accept a PR fixing it. It should also support Tuple[...] | None (as that's basically the same thing), and should error out if there is a custom parser registered for NoneType (unless a 1-element tuple type is given), as in that case the arity (number of items to read) is ill-defined.

from defopt.

and should error out if there is a custom parser registered for NoneType

Oh is this only for the optional tuple case? Or any optional container?

And do you mind providing an example of the ambiguity that a 1-element tuple avoids?

from defopt.

Say you have a parser for NoneType (def parse_none(s): return s if s == ":none:" else raise ValueError("not none")) and a function with hint def main(*, opt: Optional[tuple[str, str]): .... Remember that this is equivalent to def main(*, opt: None | tuple[str, str]) (Optional is strictly equivalent to union-with-None, and defopt always special-cases None to go first in the union). Now, the problem is that the invocation $ myscript --opt <some-arg> is valid if and only if <some-arg> is :none:, and the invocation $ myscript --opt <some-arg> <other-arg> is valid if and only if <some-arg> is not :none:, i.e. nargs for opt is not well defined (and argparse has no way to represent such options (IIRC there's a bug on CPython's tracker to request support for that)). On the other hand, for 1-element tuples, there is no ambiguity that nargs == 1.

Your point about other optional containers makes me believe that I have indeed missed that problematic interaction previously; Optional[list[str]] behaves exactly like list[str]. On the other hand, in for non-tuple containers, I think we can have a way out because they already have nargs = "*" anyways and therefore we can just do add a case checking if a single arg was passed and, if so, try to pass it to the none-parser (if it exists). (For tuples, we can't rely on using nargs = "*", as we can have multiple positional tuple parameters.)

(PS: this discussion also applies to #116, of course.)

from defopt.

Ahh got it, yeah I'll work on that when I get the chance

from defopt.

So I was able to raise an error when an optional multiple item tuple with a custom none parser is provided, but I'm a bit confused on where to make the change such that the none parser is tried first in the list/one-item tuple case. For optional primitives, trying the none parser first is more straightforward because that can happen via the type set on the ArgumentParser argument. To do this with optional containers, would that need to happen in _bind_or_bind_known somehow?

from defopt.

From a quick look, this is indeed not trivial to implement :-( and would probably require a bit of rearchitecting. Let's go for the simpler route of erroring out in all cases when a custom noneparser is present, we can always consider adding back support for the one-element case later.

from defopt.

Sure, sounds good. I imagine wanting to have an optional tuple potentially parsed as None via the command line (rather than just using a default value of None) is a pretty rare use case anyway.

from defopt.