-
Notifications
You must be signed in to change notification settings - Fork 368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fosite.Arguments: Nano optimization of .Exact() #399
Conversation
These are functionally different because before it worked for len > 1 and now it doesn’t. |
for len>1 before and after it returns |
Only case I can see them being different is that previously
do I miss something? |
that is the use case I was thinking about. While it does not appear to be used like that anywhere in fosite, it was originally implemented that way because we might have arguments where order matters / must be preserved. I'm not sure if we import this code somewhere else that depends on this behavior, thus I am hesitant to merge it. |
This should be covered by Using |
That might be, but as I explained we have other code that (might) depend on this behavior and even if you have a better naming for it, it doesn't change that fact! Breaking the functionality in such a way without e.g. renaming the function as well is not something that can be merged. If you want, you can introduce a new function |
Previously Arguments.Exact had vague semantic where it coudln't distinguish between value with a space and multiple values. Split it into 2 functions with clear semantic. Old .Exact() remains for compatibility and marked as deprecated
Added ExactOne and MatchesExact, also added tests for discussed edge cases |
Awesome, thank you! |
Previously Arguments.Exact had vague semantic where
it coudln't distinguish between value with a space and multiple
values. Split it into 2 functions with clear semantic.
Old .Exact() remains for compatibility and marked as deprecated