-
Notifications
You must be signed in to change notification settings - Fork 52
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
Union of singular type with list of types not behaving as expected. #297
Comments
Hey there @rwightman , thanks for posting! Hmmm this is clearly a bug. I'm curious though, does this happen only with strings? Or do other field types exhibit the same behaviour? |
@lebrice it behaves similarly if I change str -> int in this example |
found this as well and dove into it a bit more (from an earlier comment I deleted). Seems like the issue is that for I can fix and PR later but want to check how FieldWrapper works more. Seems like it might not actually be validating the inner annotation but I haven't checked fully. |
Thanks for looking into this @grahamannett, that's very helpful!
Hope this helps, lmk if you have other questions :) |
Yeah thanks thats helpful @lebrice. I can add a test and PR as I think the fix isn't super complicated. Just probably have to check what other expected functionality is for UnionType/List args which requires me to look at the FieldWrapper a bit more. |
Ended up being more confusing/harder than I originally thought but should fix the issue. |
Describe the bug
So this may not be a bug, but it's not clear what the expected behaviour is in any case. For class fields that are often singular but sometimes a list or tuple of values of the same type I often use
Union[type, List[type]]
in annotations. When it's a single value I accessobj.value
instead ofobj.value[0]
, there is code to check for sequences and handle appropriately.I thought this might just work with SimpleParsing, it accepts the type definition but does not behave the way I was hoping, and I cannot determine what it is supposed to do in this case, it looks like it ignores the list/tuple typing and behaves as if the field was just
type
To Reproduce
Expected behavior
A clear and concise description of what you expected to happen.
Actual behavior
A clear and concise description of what is happening.
Desktop (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: