[SciPy-dev] [pymachine] moving code outside the sandbox into scikits ?

Brian Hawthorne brian.lee.hawthorne@gmail....
Thu Jun 28 01:54:40 CDT 2007


Hi, I'm going to throw in my contrary 2 cents and say that I prefer learning
or learn.  The reasons are:
- they are shorter, and therefore easier to type
- they are shorter, and thus produce a smaller desire to abbreviate with
aliases (import x as y).  I think that's good because it reduces the number
of names/conventions that must be defined/remembered as referring to the
same thing.
- they are real words (unlike machlearn), and therefore easier to remember
and type
- adding the word machine seems redundant (I do realize that "machine
learning" is the proper name for the field), since it is software we are
talking about... I guess the only confusion that could arise is that a
newcomer might think it was a package for educating humans about scikits.

Anyway, that's all I have to say on the subject.

Cheers,
Brian

On 6/25/07, Jarrod Millman <millman@berkeley.edu> wrote:
>
> On 6/23/07, Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
> > > We have been calling the project pymachine. But we would rather use a
> > > more descriptive name for the scikit package (and one that doesn't
> > > contain 'py').  Here are some ideas:
> > > - scikits.learning
> > > - scikits.learn
> > > - scikits.machinelearning
> > > - scikits.mlearn
> > > What do you think of these names?  Does anyone have better name in
> mind?
> >
> > machinelearning is my favourite, but I would think of a more global
> > hierarchy inside this namespace. svm and em do not have the same final
> goal,
> > so perhaps adding classification or estimation as sub-sub-namespace
> would be
> > worth considering.
> >
> > Matthieu
>
> Hey Matthieu,
>
> I agree with you, scikits.machinelearning is my favorite as well.  I
> understand Dmitrey's concern about it being such a long name, but I
> think that it is much more important for the package name to be
> obvious as to what it does.  Hopefully, having a well-named package
> will make it more obvious what the very terse names like svm or em
> mean given that they are found inside a machinelearning package.  I
> also want to make sure that a good precedent is started regarding the
> naming of scikits packages.
>
> I also like your suggestion to use something like "import
> scikits.machinelearning as ml".  It might be good to even have a
> recommendation like this in the package docstring.  That way we could
> encourage the adoption of ml (for scikits.machinelearning) as a
> consistent convention.
>
> I also agree that we may need to create a nested hierarchy.  But I
> would prefer to keep a flat namespace at least for the next few weeks.
> That way we can make the hierarchy after seeing what code ends up in
> the package.  In addition to the code David is working on, there are a
> few other developers who have tentatively offered to contribute some
> working code that they have written.  But we should definitely return
> to this point before making an official release.
>
> Unless there are additional responses or concerns, I will ask David to
> go ahead with the plan starting Tuesday.  Specifically, he will create
> a new scikits package called machinelearning and start moving code out
> of the scipy sandbox.  First, he will move the support vector machine
> and expectation-maximization code:
> scipy.sandbox.pyem  -->  scikits.machinelearning.em
> scipy.sandbox.svm     -->  scikits.machinelearning.svm
> And then later he may move the genetic algorithm and neural network code:
> scipy.sandbox.ga        -->  scikits.machinelearning.ga
> scipy.sandbox.ann      -->  scikits.machinelearning.ann
>
> Thanks,
>
> --
> Jarrod Millman
> Computational Infrastructure for Research Labs
> 10 Giannini Hall, UC Berkeley
> phone: 510.643.4014
> http://cirl.berkeley.edu/
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev@scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/scipy-dev/attachments/20070627/6591843b/attachment.html 


More information about the Scipy-dev mailing list