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