Automatically create data sources as necessary from arrays, dicts, dataframes

[matthewturk]

A common operation that people want to do is, for instance, something like "Give me a phase plot of this thing!" But they may not have gone through the entire process of building out a dataset through load_uniform_grid and then selecting all_data() but it's just as valid.

One straightforward way of addressing this would be to build out a mechanism for automatically converting guessable formats into datasets. This would work nicely for things like phase plots and profile plots, but if the appropriate arrays and records are available, it could be just as useful to do this for projections and slices as well.

As a few examples:

• Dataframes from pandas: these are trivially convertable to a data source for phase plots and profile plots, even if not spatially organized.
• A dict-of-arrays could also work the same way.
• A single array (of 2 or 3 dimensions, or with an appropriate dtype) fed in could be done similarly.

For projection and slice plots, it could be something like looking for records like x, etc, and then creating the dataset based on the extent.

The endpoint might look something like:

my_data = dict( x = ..., y = ..., z = ..., density = ..., temperature = ...)
yt.PhasePlot(my_array, "density", "temperature")

This would substantially lower the barrier to entry for using yt functionality, and would not be limited to plots; this could also work for other top-level operations.

[ngoldbaum]

This would require adding more input validation in the public API (e.g. the example in the proposal would require code in PhasePlot to convert arbitrary python objects into datasets). I worry about missing places in the API that currently expect a dataset or data object but with this proposal would accept many other types of objects. It's important to keep the API consistent. I also worry about our API seeming too "magical".

What about making yt.load() return a dataset if you pass it one of these formats? I think that would require fewer changes to top-level yt API classes and functions, since they would still only accept datasets.

[matthewturk]

I'd contend that this would be a nice way of reducing the boilerplate code -- without necessarily making it considerably more magical, if we restricted it to a handful of places (such as just the visualization commands). I do think that having yt.load() do this would also be of use.