You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Marking as bug but it's one of those things I'd only want to release in a minor release...esp as it's backwards incompatible. (Soon, so soon, this would be grounds for a major release! but we're still pre 1.0...)
tl;dr try reining in Parser.check_ambiguity() so it doesn't explode when the value given is flag-like, but it would be a valid flag for the current context: it seems more likely that the user was intending to give that 2nd flag (and implicitly NOT giving a value to the optional-value flag being parsed), than that they were intending to give such a flag as a value to this one.
We might also want to remove the check around another possible context/task name, but that one seems more truly ambiguous to me so prob best to leave it.
The text was updated successfully, but these errors were encountered:
Also, while I am writing up the docs/changelogs for this, I realize - if we are happy resolving that particular ambiguity, it means the other half of it - flag-like values which are not otherwise valid for current context - can also be resolved (and preserved as the optional-value flag's string value.)
But also, I now find myself wondering why all of this did not occur to me at the time. Is there something in the parser's design that made the current behavior way more compelling than the "are you valid or not?" test?
Specifically, valid flags that come after optional-value
flags, WHICH ARE IN --x=y FORM, did not pass muster due
to how parse tokenizing worked.
This should fix it and all the other tests still pass
so holy shit I am a genius or something???
Spinoff from #33, specifically #33 (comment)
Marking as bug but it's one of those things I'd only want to release in a minor release...esp as it's backwards incompatible. (Soon, so soon, this would be grounds for a major release! but we're still pre 1.0...)
tl;dr try reining in
Parser.check_ambiguity()
so it doesn't explode when the value given is flag-like, but it would be a valid flag for the current context: it seems more likely that the user was intending to give that 2nd flag (and implicitly NOT giving a value to the optional-value flag being parsed), than that they were intending to give such a flag as a value to this one.We might also want to remove the check around another possible context/task name, but that one seems more truly ambiguous to me so prob best to leave it.
The text was updated successfully, but these errors were encountered: