This is how I approach this question:
I think a good rule of thumb is to always start with a function as the
first step of generalizing a solution.
If you see your problem / use case is settling and you find yourself
writing / calling a related set of functions related to the same problem
then think about whether having a class would make things easier.
I think the problem a class tries to solve is different from the problem a
function tries to solve.
A functions makes sense where what you need can be done in just one call
(and you won't come back afterwards) and then your problem is solved / your
task is complete.
A class is always nice if have a set of common functions you repeatedly use
for working on your problem / task where states and particular
representations for you data are helpful.


On Wed, Feb 13, 2013 at 5:09 PM, Alexandre Gramfort <
notifications@github.com> wrote:

> In mne/fiff/kit/kit.py:
>
> > +from ..raw import Raw
> > +from ...utils import verbose
> > +from ...transforms.coreg import fit_matched_pts
> > +from ..constants import FIFF
> > +from .constants import KIT, KIT_NY, KIT_AD
> > +from .import coreg
> > +from struct import unpack
> > +import numpy as np
> > +from scipy.linalg import norm
> > +import time
> > +import logging
> > +
> > +logger = logging.getLogger('mne')
> > +
> > +
> > +class sqd_params(object):
>
> https://www.youtube.com/watch?v=o9pEzgHorH0 :)
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/mne-tools/mne-python/pull/366/files#r2997960>.
>
>