Skip to content

Disable view safety checks #6562

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

Merged
merged 2 commits into from
Oct 27, 2015
Merged

Conversation

ahaldane
Copy link
Member

This PR disables the view safety checks that were causing problems in #6467, undoing some of the work from #5548. It goes back to the old behavior of disallowing any views/setfield involving object arrays.

This is better than reverting #5548, because it turns out there were other fixes in #5548 and subsequent PRs (eg #6208), plus in this PR, which fix most of the issues involving view safety without needing the safety checks. In fact, of the 5 issues fixed in #5548, only one needs to be re-opened due to this PR (#2599). (Edit: Actually #2346 needs to be re-opened too. Half of the examples there work now, but some are broken.)

I also request a day or two to sit on this before merging, please! (Ping me if I am delaying the release)

@ahaldane ahaldane force-pushed the disable_view_safety_checks branch from 579303b to 6602a20 Compare October 26, 2015 16:58
@charris charris added this to the 1.10.2 release milestone Oct 26, 2015
@ahaldane ahaldane force-pushed the disable_view_safety_checks branch from 6602a20 to 393934b Compare October 27, 2015 01:01
Remove unit tests for the view safety chekcs, which are to be reverted
in the next commit.
@ahaldane ahaldane force-pushed the disable_view_safety_checks branch 4 times, most recently from 4538d25 to 7ad5285 Compare October 27, 2015 01:46
@ahaldane
Copy link
Member Author

OK, I think this is good. Somewhat suprisingly the only issue that needs to be reopened is #2346, and I suspect even that will be fixed by #6053 without needing safety checks.

So it looks like the safety checks weren't actually needed to solve any open issues - we just needed smarter logic to handle the case of object arrays in various places. Hmm...


if oldtype.names:
for name in oldtype.names:
if (oldtype.fields[name][1] == offset and
Copy link
Member

Choose a reason for hiding this comment

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

This looks a little funny. Why is it safe to return on first instance that the condition is satisfied?

Copy link
Member

Choose a reason for hiding this comment

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

Just finding somthing that matches new type?

Copy link
Member

Choose a reason for hiding this comment

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

Why the search?

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 idea is to allow getfield as long as we are getting a field that already exists. Eg,

>>> ones(3, dtype='i4,O').setfield(5, 'O', 4)

Since get/setfield doesn't know the name of the field we have to search for the field based on the offset.

Copy link
Member

Choose a reason for hiding this comment

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

OK, got it.

@charris
Copy link
Member

charris commented Oct 27, 2015

I like that so much code is removed ;)

Because of slowdowns caused by the view safety checks introduced in
 numpy#5548 they are removed here for 1.10. The plan is to reintroduce
a better version of the checks in 1.11.
@ahaldane ahaldane force-pushed the disable_view_safety_checks branch from 7ad5285 to 796a5f8 Compare October 27, 2015 03:11
@ahaldane
Copy link
Member Author

removed the blank line

charris added a commit that referenced this pull request Oct 27, 2015
@charris charris merged commit 522a0f7 into numpy:master Oct 27, 2015
@charris
Copy link
Member

charris commented Oct 27, 2015

@ahaldane Thanks for getting this done. And the removal of code always gives me a warm, fuzzy feeling ;)

@ahaldane
Copy link
Member Author

Thanks @charris, and agreed!

Ultimately I think we will still want to allow view of arrays with objects at some point, but I'm hoping that will be easier under a new dtype system (in a year or two?), without needing these convoluted safety checks.

@embray
Copy link
Contributor

embray commented Nov 17, 2015

Thanks @ahaldane ! I'm sorry this ended up being such a hassle for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants