[yt-dev] Re: Proposal: make ambiguous field accesses raise errors in yt 4.0

On Mon, Apr 16, 2018 at 1:33 PM, Cameron Hummels wrote:

I'm in favor of this. It's more text to write the full tuple, but better in that we don't end up with yt guessing too much, and I imagine it simplifies the code a bunch too.

I've never seen the ds.fields.gas.density syntax before, but I like it. I wasn't able to find anything in the documentation about this, so perhaps it could be included at some point as we transition to using it more?

It's in the docs but only in the section describing the field system, if we want more people to use it we'd probably need to convert the docs wholesale to use the new syntax: http://yt-project.org/docs/dev/analyzing/fields.html#what-fields-are-availab...

Thanks for this, Nathan.

Cameron

On Mon, Apr 16, 2018 at 11:28 AM, Nathan Goldbaum wrote:

...

Hi all,

I'm probably going to expand this into a full YTEP but I wanted to bring this up informally to see if there are any objections to the general idea.

One of the big changes in yt 3.0 was that fields names went from bring strings to bring two-element tuples of strings. However, in an attempt to maintain compatibility with scripts written for yt 2.x, Matt added the ability for yt to "guess" a field tuple from a string field name. That's how when you do dd['density'] it gets resolved to dd['gas', 'density']. This is nice both for backward compatibility and also for the sake of ease of use.

This is fine until the guessing becomes ambiguous. At that point, the possibility exists for yt to guess wrong. The field guessing machinery also has some hysteresis, so it's possible that sometimes yt will guess correctly based on prior inputs to the field machinery and other times guess incorrectly. On python 3.4 and 3.5 even the same script can sometimes give different results because dictionary iteration order is randomized.

I don't think it's possible to improve the field detection such that yt can always guess "correctly" because the correct answer depends on user intent, which we don't really have a hope of analyzing and figuring out.

Instead, I'd like to propose a backward incompatible change for yt 4.0: *make field accesses with a string field name that resolve to more than one fields raise an error with a list of the fields that possibly match*.

Ultimately, we may want to consider deprecating string field names entirely. In my opinion it would be beneficial if we can get people to use the ds.fields object more. If you're unfamiliar with that, it's currently possible to do:

data = dd[ds.fields.gas.density]

Here `ds.fields.gas.density` is basically syntax sugar for `ds.field_info['gas, 'density']`. The nice thing about this construction is it forces people to specify the field type. It also allows people to tab complete field names in IPython.

What do you all think?

If there aren't strong objections I'm going to expand this into a YTEP, ultimately implementing it for yt 4.0.

-Nathan

_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org

-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org

_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org