Mne-python: DOC: Add contributor guidance about f-strings

[hoechenberger]

As we dropped support for Python 3.5, can we use f-strings now instead of those dreadful str.format() and '%s' % foo thingies? :-) I think in many situations, f-strings are _much_ more readable. What's the other developers' opinion on this?

[cbrnr]

YES! YES! YES! 💯

[agramfort]

No objection but do not start a PR to change everywhere. Lets do it new code or when we need to touch old code

[hoechenberger]

No objection but do not start a PR to change everywhere. Lets do it new code or when we need to touch old code

That's exactly what I had in mind, sorry for not being clear in the beginning!

• Use f-strings in new code when appropriate
• Only change existing code when necessary

[drammock]

I'm also in favor, though I guess we don't really need to keep this issue open? Unless @hoechenberger wants to add a sentence to the contributor guide about it...

[hoechenberger]

I just wanted to hear your opinions :) I can add a couple words to the contributor guide, sure!

[larsoner]

Yes the informal policy is that once we bump a requirement (incl. Python) we start using features available from that requirement where / when it's useful to do so, assuming people agree that those features are useful compared to what we've been doing. For example

• we no longer need to use OrderedDict because dict maintains order in 3.6+
• we started using np.mean(x, axis=0, keepdims=True) instead of np.mean(x, axis=0)[np.newaxis] once we bumped to a NumPy requirement that had keepdims
• we never transitioned to prefer .format over % string because the benefits weren't clear enough to everyone / it had its own drawbacks

f-syntax strings are probably nicer enough to prefer them going forward, though.

Feel free to add some variant of this to the dev docs if you want to semi-formalize the policy