Repository: mne-tools/mne-python

Issue:
epochs[['foo', 'bar']] bug
Let's say you have an epochs object which you believe has labels 'foo' and 'bar', but really 'bar' doesn't exist as a label in the object.

epochs['bar'].average() throws an error, which seems reasonable

epochs[['foo', 'bar']].average() does not throw an error while it should.


Discussion:
I'm not convinced. So far the `[a, b]` has been thought of as `a or b`. This is consistent with that idea.
I would say that at a minimum it should issue a warning. I also can't generate epochs like this, because if i supply an event_id that has doesn't have any events I get an exception
`ValueError: No matching events found for test (event id 21)`

Relatedly, I would love to see a method that would list the available labels within an epochs objects. I know `epochs.event_id` has the events in it but for nested(hierarchical) events this doesn't quite work. For instance `{'Prime/Nonwords': 3, 'Prime/Related': 1, 'Prime/Unrelated': 2}` Should have 4 possible labels `'Prime' , 'Prime/Nonwords', 'Prime/Related', 'Prime/Unrelated'`
> I also can't generate epochs like this, because if i supply an event_id that has doesn't have any events I get an exception

This is controllable via the `on_missing` parameter of `Epochs`. People who have used this option in conjunction with the existing `or`-like logic will thus experience a backward-incompatible code change by the proposed change here.

> For instance {'Prime/Nonwords': 3, 'Prime/Related': 1, 'Prime/Unrelated': 2} Should have 4 possible labels 'Prime' , 'Prime/Nonwords', 'Prime/Related', 'Prime/Unrelated'

There are actually more possibilities than this, though, right? You could also pass any of `['Nonwords', 'Related', 'Unrelated']` and get epochs. 

can we find a middle ground here?
> epochs[['foo', 'bar']].average() does not throw an error while it should.

This proposal would break existing reasonable code. I think we need to describe to people that `epochs[[a, b]]` is an OR-like operation, so even if `a` or `b` is not present, no error will occur as long as one of them will.

Argubly, the most consistent thing would be to allow `epochs[a]` to work and return an empty epochs object...
We should probably doc it better, specify under `epochs.__getitem__` that `epochs[[...]]` is an `or`.
PR welcome...

I would add a section on indexing Epochs in 

http://martinos.org/mne/stable/auto_tutorials/plot_object_epochs.html

arguably I would have expected to such a section to already exist... But I don't know where hum ...

Resolving patch:
diff --git a/tutorials/plot_object_epochs.py b/tutorials/plot_object_epochs.py
--- a/tutorials/plot_object_epochs.py
+++ b/tutorials/plot_object_epochs.py
@@ -75,6 +75,30 @@
 print(epochs[1:5])
 print(epochs['Auditory/Right'])
 
+###############################################################################
+# Note the '/'s in the event code labels. These separators allow tag-based
+# selection of epoch sets; every string separated by '/' can be entered, and
+# returns the subset of epochs matching any of the strings. E.g.,
+
+print(epochs['Right'])
+print(epochs['Right', 'Left'])
+
+
+###############################################################################
+# Note that MNE will not complain if you ask for tags not present in the
+# object, as long as it can find some match: the below example is parsed as
+# (inclusive) 'Right' OR 'Left'. However, if no match is found, an error is
+# returned.
+
+epochs_r = epochs['Right']
+epochs_still_only_r = epochs_r[['Right', 'Left']]
+print(epochs_still_only_r)
+
+try:
+    epochs_still_only_r["Left"]
+except KeyError:
+    print("Tag-based selection without any matches raises a KeyError!")
+
 ###############################################################################
 # It is also possible to iterate through :class:`Epochs <mne.Epochs>` objects
 # in this way. Note that behavior is different if you iterate on `Epochs`


Test patch: