Skip to content

BUG: Fix failures in master related to userdtype registeration#17501

Merged
mattip merged 2 commits intonumpy:masterfrom
seberg:fix-master-failure
Oct 8, 2020
Merged

BUG: Fix failures in master related to userdtype registeration#17501
mattip merged 2 commits intonumpy:masterfrom
seberg:fix-master-failure

Conversation

@seberg
Copy link
Member

@seberg seberg commented Oct 8, 2020

There are two failures that needed fixing here:

  1. If a legacy user dtype has a dype.type which does not subclass from np.generic, we do not use the type during dtype discovery in np.array([...]), so I must not set up such a mapping, but current master did set it up.

  2. Because xpress was missing the error, it seemed safer to keep the typenumber as -1 if there is a failure during creating the DType. But I pushed setting the type number too far back, meaning that it ended up as -1 on the DType class. That, together with other changes probably, caused master to fail.

This is the fix instead of the revert in gh-17499

seberg added 2 commits October 7, 2020 23:11
These are now accepted (as a no-op) in `_PyArray_MapPyTypeToDType`
retaining previous behaviour (as lookup for a registered user-type
was only done if the instance check suceeded.

Retain the check for future user DTypes, as it sould be a conscience
choice to relax this requirement.
This slightly rearranges the code to ensure that the type number
set for a user type is -1 (invalid) if it does not succeed.
(This should be unnecessary, but might be relevant in the unlikely
event that a usertype does not check the error return correctly.)

with pytest.raises(RuntimeError):
# Registering a second time should fail
create_custom_field_dtype(blueprint, mytype, 0)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test only made sense because I mapped the pytype -> dtype, but for legacy user-dtypes where the pytype does not subclass np.generic we actually do not do that, so testing for this error was actually incorrect.

@mattip
Copy link
Member

mattip commented Oct 8, 2020

Thanks @seberg

@seberg seberg deleted the fix-master-failure branch October 8, 2020 05:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Comments