more consistent class instances/types

It is unintuitive and surprising (at least to me and @jasmainak) that:

my_epochs = mne.read_epochs('my_data-epo.fif.gz')
isinstance(my_epochs, mne.Epochs)  # returns False ?!!

It would be nice if mne.epochs.EpochsFIF were a subclass of mne.Epochs so that type checking were more straightforward. Similar argument applies to the various different types of Raw objects. @Eric89GXL has suggested (on Gitter) making _baseEpochs public as one solution, with a caveat in the docstring that it shouldn’t be instantiated directly in user code.

[jona-sassenhagen]

On 23 Nov 2016, at 16:58, Denis A. Engemann [e-mail] wrote:

I keep being -1000 against .to_epochs method. The way of constructing Epochs is not broken and does not need a fix and is a robust and well working routine. As @agramfort says we don’t need more magic here and it is good force users to know explicitly how they want to construct epochs.

To be fair, the issue of “magic” is orthogonal to the issue of adding a method; the method could in principle be set to require the same input as the current constructor (minus the Raw instance), and we have recently simplified the current constructor to perform some magic.

[jasmainak]

@drammock let’s not try to overfit and be perfect. Perfect is the enemy of good (and also done) 😃 These things are not obvious when you start a library and it is only apparent in retrospect. We should be a bit more patient before suggesting an overhaul. There are many more urgent things to be done than a class overhaul for a GSoC. I’m sure we can live with minor inconveniences.

Among the suggestions so far, I like my own epochs_types of course – because it has a ring of familiarity and also because it offers a public API without exposing the entire class. But I can also live with making _BaseEpochs public if this is what everyone prefers. Please make a PR if you are up for it!