[SciPy-dev] [pymachine] moving code outside the sandbox into scikits ?
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
- they are real words (unlike machlearn), and therefore easier to remember
- 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.
On 6/25/07, Jarrod Millman <firstname.lastname@example.org> wrote:
> On 6/23/07, Matthieu Brucher <email@example.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
> > 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
> > 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
> Jarrod Millman
> Computational Infrastructure for Research Labs
> 10 Giannini Hall, UC Berkeley
> phone: 510.643.4014
> Scipy-dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Scipy-dev