A use case for this functionality is described in cbrnr/mnelab#5

Looks reasonable to me, but not travis.

Can you check for relative speed improvements or regressions? I know the function overhead will be small but it might be used a lot of places in the code. Using OrderedDict with channels ordered roughly by how often they get picked (EEG, MEG, STIM, ECG, EOG?) entered first might make things faster in most use cases, for example.

Did you look at channel_indices_by_type to see if it would suit your use case already?

If you have time, can you look to see if there is a way to (finally!) deduplicate the logic here with that of pick_types now that you've done some standardization?

Codecov Report

Merging #4842 into master will increase coverage by 0.02%.
The diff coverage is 90%.

@@            Coverage Diff             @@
##           master    #4842      +/-   ##
==========================================
+ Coverage   83.66%   83.68%   +0.02%     
==========================================
  Files         348      348              
  Lines       62435    62401      -34     
  Branches    10738    10719      -19     
==========================================
- Hits        52237    52222      -15     
+ Misses       7442     7434       -8     
+ Partials     2756     2745      -11

Looks reasonable to me, but not travis.

Should be fixed. I assumed that the keys always existed.

Can you check for relative speed improvements or regressions? I know the function overhead will be small but it might be used a lot of places in the code. Using OrderedDict with channels ordered roughly by how often they get picked (EEG, MEG, STIM, ECG, EOG?) entered first might make things faster in most use cases, for example.

Let's check how often this function is called before prematurely optimizing.

Did you look at channel_indices_by_type to see if it would suit your use case already?

No, I really need to know all supported channel types, not just the ones in the current data set.

If you have time, can you look to see if there is a way to (finally!) deduplicate the logic here with that of pick_types now that you've done some standardization?

OMG, I thought this would be a nice and quick PR 😝 . Yes, I'll take a look, but let's first assert that my change is usable in the first place before deduplicating this.

Let's check how often this function is called before prematurely optimizing.

Right now git grep "channel_type(" gives 27 direct results. Functions that call those could multiply the effect. But it's not currently used by pick_* functions which will help limit its impact.

A quick check would be to try something like pytest mne/io before and after the PR to make sure nothing big changes.

When combined with the deduplication idea (something we should do eventually), it would be used any time a pick_* function would be used, though. So we'd need to look at speed then.

OMG, I thought this would be a nice and quick PR

Yes that's why I added the "if you have time" -- it's not essential for this PR, but if you're in the mode to do it, it would be appreciated :)

All tests (except the OSX ones) pass. Now on to the timing question.

Master branch:

%timeit [mne.io.pick.channel_type(raw.info, idx) for idx in range(raw.info["nchan"])]
86.8 µs ± 1.51 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

This PR:

%timeit [mne.io.pick.channel_type(raw.info, idx) for idx in range(raw.info["nchan"])]
88.5 µs ± 2.11 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

pytest mne/io seems to be too variable to use as a reliable estimate of speed changes of this PR.

And yes, as @larsoner mentioned deduplicating this is important! I just saw that this is also used in meas_info.py in create_info. Let's not forget to to that after this PR.

+1 for MRG when CIs are happy