Make Ensemble._*_col public

[hombit]

Ensemble.batch(func, *args) requires the user to assign *args with column names. A simple and dataset-agnostic way to do it is specifying it via Ensemble object itself:

ens.batch(func, ens._time_col, ens._flux_col)

However, by Python convention, object attributes staring with _ are not the part of the public interface and user should avoid using them. I suggest removing this prefix to have ens.time_col, ens.flux_col, etc instead. If we have a good reason to prevent the user from accidental change of these values, we could have private ens.__time_col and public read-only property, following this pattern:

class C:
    def __init__(self, x):
        self.__x = x
    @property
    def x(self):
        return self.__x

[dougbrn]

The original intent was to shield these a bit from users, particularly with some aversion to users being able to assign something like ens.time_col at will. However, as we've developed and used TAPE more and more, it is apparent that users should be able to access these. I think I'm in favor of the property implementation here over making them directly part of the public interface. But that's not a strong preference.

I do think we should hold off on this until the refactor is complete, as these will likely be properties of the SourceFrame and ObjectFrame, and we may need to think a bit about the best way to show them from the ensemble level (if we want to at all)

[nevencaplar]

In similar vein, I would advocate for making Ensemble()._object and Ensemble()._source public (Ensemble().object and Ensemble().source). For instance, we use the Ensemble()._source in help docs. So it does seem that we want these to be public (and I see that I want to use them)

[wilsonbb]

I do have a draft PR for making Ensemble()._object and Ensemble()._source public. I can go ahead and send it out if people are ok with having to fix their local notebooks after the API change.

[dougbrn]

That sounds good to me if you already have it ready to go 👍

[dougbrn]

@hombit How does this change, if at all, with #261?

Once we have #261, we'll be able to return series objects for the critical columns. Obviously the _flux_col variables are returning the string name, not the critical columns. But users would be able to get the names presumably doing something like this:
ens.source.flux.name (or ens.flux.name if it lived at the ensemble level). Is there an advantage to protecting the internally used labels, while giving users a single property interface to get at data and columns names as needed?

[hombit]

.name solution sounds good to me!

We potentially could also think about some sugar and let users pass both names and column objects, e.g. "flux" or ens.flux. But it could go to a separate issue to be implemented later

[dougbrn]

Closing this, as #261 will implement.