YTEP-0018: Changing dict-like access to Static Output

Abstract

Created: September 18, 2013 Author: Matthew Turk

Currently, accessing a StaticOutput like a dictionary will check the parameters, units, time_units and conversion_factors dictionaries. This YTEP proposes changing it such that no dictionaries will be queried.

Status

Proposed

Project Management Links

There are no easily-identified project management links. However, it should be noted that over the years, numerous times confusion has arisen as to what things like pf[“Time”] refer to.

Detailed Description

The conflation of parameters, conversion factors, units and so on causes an enormous amount of confusion. The most common uses of this are:

• Length conversions such as: 1.0/pf[‘cm’]
• Accessing parameters
• Occasional unit conversions (typically this causes more problems than it solves)

However, the degeneracy that often arises between unit conversions and parameter access is typically quite problematic. This proposes that we simplify the entire procedure to disable all dict-like access, and ensure that individuals access .parameters explicitly. This may be unintuitive and will cause large changes to user-facing code, so we may consider re-enabling it.

The difficulty in ensuring that conversions can be conducted in a separate manner arises from the variable conversion factors even within a given frontend; particularly for cosmology simulations, these conversion factors (length, time, etc) change over time.

To implement this, we will ensure that:

1. All places that require a length unit accept a tuple. This is nearly if not completely implemented.
2. For a specified time (until 3.1 is released), dict-like access to the StaticOutput object will raise a deprecation warning if the key is not found in parameters. This can be elevated to an exception upon request by the user.
3. Ensure the test-suite passes.
4. Update all documentation and examples.

By stepping into this gradually, we will follow the example set forth by the field refactor and enable individuals to see that the behavior is changing without mandating an immediate switch.

Backwards Compatibility

In 3.0, this will not break scripts; deprecation warnings will be issued. In 3.1, this will break a considerable number of scripts that rely on unit conversions mediated by the StaticOutput object. This is very worrisome and will require the graduated change to disabling dict-like access.

Alternatives

We can continue allowing this behavior, but it will continue to cause confusion and impede progress toward a cleaner API.