Skip to content

Use explicit type check in as_compatible_data instead of blanket access to values attribute #2905

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

Conversation

blsqr
Copy link
Contributor

@blsqr blsqr commented Apr 17, 2019

This change was prompted by the fact that getattr(data, 'values', data)
affected any kind of data with a values attribute, which is not the
desired behaviour for core.variable.as_compatible_data.

This also extends tests to assert that custom objects with such an
attribute are not attempted to be converted.

I'm happy to write additional tests, if you could briefly sketch further requirements.

blsqr added 2 commits April 17, 2019 23:33
This change was prompted by the fact that `getattr(data, 'values', data)`
affected any kind of data with a `values` attribute, which is not the
desired behaviour at that point.

This also extends tests to assert that custom objects with such an
attribute are not attempted to be converted
@pep8speaks
Copy link

pep8speaks commented Apr 17, 2019

Hello @blsqr! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2019-12-01 15:58:23 UTC

@blsqr blsqr changed the title Use explicit type check in as_compatible_data instead of blanket access to values attribute [WIP] Use explicit type check in as_compatible_data instead of blanket access to values attribute Apr 18, 2019
@dcherian
Copy link
Contributor

dcherian commented Sep 7, 2019

Thanks @blsqr. The tests are failing at this line:
orig = Variable(dims=('x'), data=array, attrs={'foo': 'bar'})

so your change isn't working yet. Can you fix it?

blsqr and others added 2 commits November 30, 2019 15:48
This change was prompted by the fact that `getattr(data, 'values', data)`
affected any kind of data with a `values` attribute, which is not the
desired behaviour at that point.

This also extends tests to assert that custom objects with such an
attribute are not attempted to be converted
@dcherian dcherian force-pushed the enhancement/more-explicit-type-check-in-as_compatible_data branch from 5e3aea2 to 2dc7f9f Compare November 30, 2019 20:49
blsqr added 2 commits December 1, 2019 16:50
…ata' of github.com:blusquare/xarray into enhancement/more-explicit-type-check-in-as_compatible_data
@blsqr
Copy link
Contributor Author

blsqr commented Dec 1, 2019

@dcherian The most recent pipeline now fails in the TestRasterio.test_rasterio_vrt test. This seems unrelated... but I'm not sure if they might be connected.

Could you give me a hint on how to continue? Or need this be fixed elsewhere (or is already fixed) and I need to update this topic branch?

@dcherian
Copy link
Contributor

dcherian commented Dec 1, 2019

We can ignore that for now.

@dcherian
Copy link
Contributor

dcherian commented Dec 1, 2019

I'm not sure that Variable is wrapping this CustomValues thing properly though. Someone else will need to chime in.

@keewis
Copy link
Collaborator

keewis commented Feb 17, 2021

@blsqr, I'm sorry for taking so long to review this. I updated your PR so this should be ready for merging.

I'm not sure that Variable is wrapping this CustomValues thing properly though.

that turned out not to be true, we can't wrap it in a list because then as_compatible_data wouldn't be able to find .values. Instead, Variable(dims=(), data=array) (or converting it to a duckarray) is the way to go.

@blsqr
Copy link
Contributor Author

blsqr commented Feb 18, 2021

@keewis Thanks for looking into this and updating the PR! :)

@blsqr blsqr changed the title [WIP] Use explicit type check in as_compatible_data instead of blanket access to values attribute Use explicit type check in as_compatible_data instead of blanket access to values attribute Feb 18, 2021
@keewis
Copy link
Collaborator

keewis commented Feb 18, 2021

thanks again, @blsqr

@keewis keewis merged commit c9b9eec into pydata:master Feb 18, 2021
@blsqr blsqr deleted the enhancement/more-explicit-type-check-in-as_compatible_data branch February 18, 2021 17:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Variable.__setitem__ coercing types on objects with a values property
4 participants