BUG: Do not inherit flags from the structured part of a union dtype #16817
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
void
dtype, 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.