BUG: Do not inherit flags from the structured part of a union dtype#16817
Merged
seberg merged 1 commit intonumpy:masterfrom Jul 13, 2020
Merged
BUG: Do not inherit flags from the structured part of a union dtype#16817seberg merged 1 commit intonumpy:masterfrom
seberg merged 1 commit intonumpy:masterfrom
Conversation
Such a union dtype (I would like to just not have them...) should behave like the main dtype normally. The only use of the union part should be to allow field access. In all other cases behaviour should not be affected by the existance of fields, but inheriting fields will affect it. The exception is the `void` dtype, which explicitly uses its fields and thus must inherit flags from the contained dtypes.
Member
Author
|
Hmmm, the azure error is about |
Member
|
close/open to clear the azure error |
Member
|
Not sure what is going on with shippable. Let's try again. |
Member
Author
|
Thanks for having a look matti. I will put this in, CI is passing now (aside from the Shippable issue). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Such a union dtype (I would like to just not have them...) should
behave like the main dtype normally. The only use of the union
part should be to allow field access. In all other cases behaviour
should not be affected by the existance of fields, but inheriting
fields will affect it.
The exception is the
voiddtype, which explicitly uses its fieldsand thus must inherit flags from the contained dtypes.
This fixes an annoying bug with such union dtypes (specifically union of objects), which came back to bite me in another cleanup (for, quite honestly reasons I did not yet understand). In any case, I am sure that this is the right way to do handle it here. Union dtypes are weird, and I would like them not existing, but tagging on fields to a dtype should definitely not change its main behaviour.