glue-jupyter

glue-jupyter copied to clipboard

The first in a series of issues that are "confusing elements of the API" from work on #28 :

I find the glue Data classes a bit difficult to work with in a notebook context. It seems natural to create Data objects and pass them into multiple places in glue, but because Data objects are tied to a glue app you can get into trouble.

So I'd say in the glupyter workflow, perhaps data objects are sort of an "implementation detail"? That is, the user should be expected to generally app.add_data which should then automatically wrap the input in Data (although then the Data constructor has to be rather flexible...).

This works now with add_data, so this issue might be more of a documentation item that it should just be stated that's the preferred way.

Thinking more about this, I agree it would be nice to have a way to preserve access to the original data API. I think one of the tricky (but not impossible) aspects will be to have a good way to detect when those objects are changed - e.g. with a Table object, how do we know when a column has been added or a cell changed?

As discussed at STScI this week, we should have a registry of converters to convert high level objects <-> glue data objects. In addition, we could provide an API that looks something like this:

>>> dc['image']   # note indexing by data *name* which doesn't work yet
<glue data object>
>>> dc.get_object('image')
<CCDData object>
>>> dc['image'].subsets[0]
<glue Subset object>
>>> dc.get_subset_object('image', subset=0)
<CCDData object with masked values>
>>> dc.get_selection_region('image, subset=0)
<astropy Region object>

@eteq - is that a reasonable summary of our decision about high-level objects?

I'm not sure if we put this in some other issue, but for some added context, this gist gives some examples of what might work better too: https://gist.github.com/eteq/067d9c52ec0c20137bb5adb17da4613c