We use Git for version control and
GitHub for hosting our main repository.

You can check out the latest sources with the command:

git clone git://github.com/scikit-learn/scikit-learn.git

or if you have write privileges:

git clone git@github.com:scikit-learn/scikit-learn.git

If you run the development version, it is cumbersome to reinstall the
package each time you update the sources. It is thus preferred that
you add the scikit-learn directory to your PYTHONPATH and build the
extension in place:

python setup.py build_ext --inplace

On Unix-like systems, you can simply type make in the top-level folder to
build in-place and launch all the tests. Have a look at the Makefile for
additional utilities.

Fork the project repository: click on the ‘Fork’
button near the top of the page. This creates a copy of the code under your
account on the GitHub server.

Clone this copy to your local disk:

$ git clone git@github.com:YourLogin/scikit-learn.git

Create a branch to hold your changes:

$ git checkout -b my-feature

and start making changes. Never work in the master branch!

Work on this copy, on your computer, using Git to do the version
control. When you’re done editing, do:

$ git add modified_files
$ git commit

to record your changes in Git, then push them to GitHub with:

$ git push -u origin my-feature

Finally, go to the web page of the your fork of the scikit-learn repo,
and click ‘Pull request’ to send your changes to the maintainers for review.
request. This will send an email to the committers, but might also send an
email to the mailing list in order to get more visibility.

Note

In the above setup, your origin remote repository points to
YourLogin/scikit-learn.git. If you wish to fetch/merge from the main
repository instead of your forked one, you will need to add another remote
to use instead of origin. If we choose the name upstream for it, the
command will be:

When applicable, use the Validation tools and other code in the
sklearn.utils submodule. A list of utility routines available
for developers can be found in the Utilities for Developers page.

All public methods should have informative docstrings with sample
usage presented as doctests when appropriate.

All other tests pass when everything is rebuilt from scratch. On
Unix-like systems, check with (from the toplevel source folder):

$ make

When adding additional functionality, provide at least one example script
in the examples/ folder. Have a look at other examples for reference.
Examples should demonstrate why the new functionality is useful in
practice and, if possible, compare it to other methods available in
scikit-learn.

At least one paragraph of narrative documentation with links to
references in the literature (with PDF links when possible) and
the example. For more details on writing and building the
documentation, see the Documentation section.

You can also check for common programming errors with the following tools:

The current state of the scikit-learn code base is not compliant with
all of those guidelines, but we expect that enforcing those constraints
on all new contributions will get the overall code base quality in the
right direction.

A great way to start contributing to scikit-learn is to pick an item from the
list of Easy issues
in the issue tracker. Resolving these issues allow you to start contributing
to the project without much prior knowledge. Your assistance in this area will
be greatly appreciated by the more experienced developers as it helps free up
their time to concentrate on other issues.

We are glad to accept any sort of documentation: function docstrings,
reStructuredText documents (like this one), tutorials, etc. reStructuredText
documents live in the source code repository under the doc/ directory.

You can edit the documentation using any text editor, and then generate the
HTML output by typing makehtml from the doc/ directory. Alternatively,
makehtml-noplot can be used to quickly generate the documentation without
the example gallery. The resulting HTML files will be placed in _build/html/
and are viewable in a web browser. See the README file in the doc/ directory
for more information.

When you are writing documentation, it is important to keep a good
compromise between mathematical and algorithmic details, and give
intuition to the reader on what the algorithm does.

Basically, to elaborate on the above, it is best to always
start with a small paragraph with a hand-waiving explanation of what the
method does to the data. Then, it is very helpful
to point out why the feature is useful and when it should be used -
the latter also including “big O”
()
complexities of the algorithm, as opposed to just rules of thumb,
as the latter can be very machine-dependent.
If those complexities are not available, then rules of thumb
may be provided instead.

Secondly, a generated figure from an example (as mentioned in the previous
paragraph) should then be included to further provide some
intuition.

Next, one or two small code examples to show its use can be added.

Finally, any math and equations, followed by references,
can be added to further the documentation. Not starting the
documentation with the maths makes it more friendly towards
users that are just interested in what the feature will do, as
opposed to how it works “under the hood”.

Warning

Sphinx version

While we do our best to have the documentation build under as many
version of Sphinx as possible, the different versions tend to behave
slightly differently. To get the best results, you should use version
1.0.

High-quality unit testing
is a corner-stone of the sciki-learn development process. For this
purpose, we use the nose
package. The tests are functions appropriately names, located in tests
subdirectories, that check the validity of the algorithms and the
different options of the code.

The full scikit-learn tests can be run using ‘make’ in the root folder.
Alternatively, running ‘nosetests’ in a folder will run all the tests of
the corresponding subpackages.

We expect code coverage of new features to be at least around 90%.

Note

Workflow to improve test coverage

To test code coverage, you need to install the coverage package in addition to nose.

Run ‘make test-coverage’. The output lists for each file the line
numbers that are not tested.

Find a low hanging fruit, looking at which lines are not tested,
write or adapt a test specifically for these lines.

Code is not the only way to contribute to scikit-learn. For instance,
documentation is also a very important part of the project and often
doesn’t get as much attention as it deserves. If you find a typo in
the documentation, or have made improvements, do not hesitate to send
an email to the mailing list or submit a GitHub pull request. Full
documentation can be found under the doc/ directory.

It also helps us if you spread the word: reference the project from your blog
and articles, link to it from your website, or simply say “I use it”:

The following are some guidelines on how new code should be written. Of
course, there are special cases and there will be exceptions to these
rules. However, following these rules when submitting new code makes
the review easier so new code can be integrated in less time.

Uniformly formatted code makes it easier to share code ownership. The
scikit-learn project tries to closely follow the official Python guidelines
detailed in PEP8 that
detail how code should be formatted and indented. Please read it and
follow it.

In addition, we add the following guidelines:

Use underscores to separate words in non class names: n_samples
rather than nsamples.

Avoid multiple statements on one line. Prefer a line return after
a control flow statement (if/for).

Use relative imports for references inside scikit-learn.

Unit tests are an exception to the previous rule;
they should use absolute imports, exactly as client code would.
A corollary is that, if sklearn.foo exports a class or function
that is implemented in sklearn.foo.bar.baz,
the test should import it from sklearn.foo.

Please don’t use ``import *`` in any case. It is considered harmful
by the official Python recommendations.
It makes the code harder to read as the origin of symbols is no
longer explicitly referenced, but most important, it prevents
using a static analysis tool like pyflakes to automatically
find bugs in scikit-learn.

The module sklearn.utils contains various functions for doing input
validation and conversion. Sometimes, np.asarray suffices for validation;
do not use np.asanyarray or np.atleast_2d, since those let NumPy’s
np.matrix through, which has a different API
(e.g., * means dot product on np.matrix,
but Hadamard product on np.ndarray).

In other cases, be sure to call safe_asarray, atleast2d_or_csr,
as_float_array or array2d on any array-like argument passed to a
scikit-learn API function. The exact function to use depends mainly on whether
scipy.sparse matrices must be accepted.

If your code depends on a random number generator, do not use
numpy.random.random() or similar routines. To ensure
repeatability in error checking, the routine should accept a keyword
random_state and use this to construct a
numpy.random.RandomState object.
See sklearn.utils.check_random_state in Utilities for Developers.

If you use randomness in an estimator instead of a freestanding function,
some additional guidelines apply.

First off, the estimator should take a random_state argument to its
__init__ with a default value of None.
It should store that argument’s value, unmodified,
in an attribute random_state.
fit can call check_random_state on that attribute
to get an actual random number generator.
If, for some reason, randomness is needed after fit,
the RNG should be stored in an attribute random_state_.
The following example should make this clear:

classGaussianNoise(BaseEstimator,TransformerMixin):"""This estimator ignores its input and returns random Gaussian noise. It also does not adhere to all scikit-learn conventions, but showcases how to handle randomness. """def__init__(self,n_components=100,random_state=None):self.random_state=random_state# the arguments are ignored anyway, so we make them optionaldeffit(self,X=None,y=None):self.random_state_=check_random_state(self.random_state)deftransform(self,X):n_samples=X.shape[0]returnself.random_state_.randn(n_samples,n_components)

The reason for this setup is reproducibility:
when an estimator is fit twice to the same data,
it should produce an identical model both times,
hence the validation in fit, not __init__.

If any publicly accessible method, function, attribute or parameter
is renamed, we still support the old one for two releases and issue
a deprecation warning when it is called/passed/accessed.
E.g., if the function zero_one is renamed to zero_one_loss,
we add the decorator deprecated (from sklearn.utils)
to zero_one and call zero_one_loss from that function:

All scikit-learn code should work unchanged in both Python 2.[67]
and 3.2 or newer. Since Python 3.x is not backwards compatible,
that may require changes to code and it certainly requires testing
on both 2.6 or 2.7, and 3.2 or newer.

For most numerical algorithms, Python 3.x support is easy:
just remember that print is a function and
integer division is written //.
String handling has been overhauled, though, as have parts of
the Python standard library.
The six package helps with
cross-compatibility and is included in scikit-learn as
sklearn.externals.six.

To have a uniform API, we try to have a common basic API for all the
objects. In addition, to avoid the proliferation of framework code, we
try to adopt simple conventions and limit to a minimum the number of
methods an object must implement.

The API has one predominant object: the estimator. A estimator is an
object that fits a model based on some training data and is capable of
inferring some properties on new data. It can be, for instance, a
classifier or a regressor. All estimators implement the fit method:

estimator.fit(X,y)

All built-in estimators also have a set_params method, which sets
data-independent parameters (overriding previous parameter values passed
to __init__).

All estimators in the main scikit-learn codebase should inherit from
sklearn.base.BaseEstimator.

This concerns the creation of an object. The object’s __init__ method
might accept constants as arguments that determine the estimator’s behavior
(like the C constant in SVMs). It should not, however, take the actual training
data as an argument, as this is left to the fit() method:

clf2=SVC(C=2.3)clf3=SVC([[1,2],[2,3]],[-1,1])# WRONG!

The arguments accepted by __init__ should all be keyword arguments
with a default value. In other words, a user should be able to instantiate
an estimator without passing any arguments to it. The arguments should all
correspond to hyperparameters describing the model or the optimisation
problem the estimator tries to solve. These initial arguments (or parameters)
are always remembered by the estimator.
Also note that they should not be documented under the “Attributes” section,
but rather under the “Parameters” section for that estimator.

In addition, every keyword argument accepted by ``__init__`` should
correspond to an attribute on the instance. Scikit-learn relies on this to
find the relevant attributes to set on an estimator when doing model selection.

There should be no logic, not even input validation,
and the parameters should not be changed.
The corresponding logic should be put where the parameters are used,
typically in fit.
The following is wrong:

def__init__(self,param1=1,param2=2,param3=3):# WRONG: parameters should not be modifiedifparam1>1:param2+=1self.param1=param1# WRONG: the object's attributes should have exactly the name of# the argument in the constructorself.param3=param2

The reason for postponing the validation is that the same validation
would have to be performed in set_params,
which is used in algorithms like GridSearchCV.

The next thing you will probably want to do is to estimate some
parameters in the model. This is implemented in the fit() method.

The fit() method takes the training data as arguments, which can be one
array in the case of unsupervised learning, or two arrays in the case
of supervised learning.

Note that the model is fitted using X and y, but the object holds no
reference to X and y. There are, however, some exceptions to this, as in
the case of precomputed kernels where this data must be stored for use by
the predict method.

Parameters

X

array-like, with shape = [N, D], where N is the number
of samples and D is the number of features.

y

array, with shape = [N], where N is the number of
samples.

kwargs

optional data-dependent parameters.

X.shape[0] should be the same as y.shape[0]. If this requisite
is not met, an exception of type ValueError should be raised.

y might be ignored in the case of unsupervised learning. However, to
make it possible to use the estimator as part of a pipeline that can
mix both supervised and unsupervised transformers, even unsupervised
estimators are kindly asked to accept a y=None keyword argument in
the second position that is just ignored by the estimator.

The method should return the object (self). This pattern is useful
to be able to implement quick one liners in an IPython session such as:

y_predicted=SVC(C=100).fit(X_train,y_train).predict(X_test)

Depending on the nature of the algorithm, fit can sometimes also
accept additional keywords arguments. However, any parameter that can
have a value assigned prior to having access to the data should be an
__init__ keyword argument. fit parameters should be restricted
to directly data dependent variables. For instance a Gram matrix or
an affinity matrix which are precomputed from the data matrix X are
data dependent. A tolerance stopping criterion tol is not directly
data dependent (although the optimal value according to some scoring
function probably is).

Attributes that have been estimated from the data must always have a name
ending with trailing underscore, for example the coefficients of
some regression estimator would be stored in a coef_ attribute after
fit has been called.

The last-mentioned attributes are expected to be overridden when
you call fit a second time without taking any previous value into
account: fit should be idempotent.

If you want to implement a new estimator that is scikit-learn-compatible,
whether it is just for you or for contributing it to sklearn, there are several
internals of scikit-learn that you should be aware of in addition to the
sklearn API outlined above.

The main motivation to make a class compatible to the scikit-learn estimator
interface might be that you want to use it together with model assessment and
selection tools such as grid_search.GridSearchCV.

For this to work, you need to implement the following interface.
If a dependency on scikit-learn is okay for your code,
you can prevent a lot of boilerplate code
by deriving a class from BaseEstimator
and optionally the mixin classes in sklearn.base.
E.g., here’s a custom classifier:

All sklearn estimator have get_params and set_params functions.
The get_params function takes no arguments and returns a dict of the
__init__ parameters of the estimator, together with their values.
It must take one keyword argument, deep,
which receives a boolean value that determines
whether the method should return the parameters of sub-estimators
(for most estimators, this can be ignored).
The default value for deep should be true.

The set_params on the other hand takes as input a dict of the form
'parameter':value and sets the parameter of the estimator using this dict.

While the get_params mechanism is not essential (see Cloning below),
the set_params function is necessary as it is used to set parameters during
grid searches.

The easiest way to implement these functions, and to get a sensible
__repr__ method, is to inherit from sklearn.base.BaseEstimator. If you
do not want to make your code dependent on scikit-learn, the easiest way to
implement the interface is:

defget_params(self,deep=True):# suppose this estimator has parameters "alpha" and "recursive"return{"alpha":self.alpha,"recursive":self.recursive}defset_params(self,**parameters):forparameter,valueinparameters.items():self.setattr(parameter,value)

As grid_search.GridSearchCV uses set_params
to apply parameter setting to estimators,
it is essential that calling set_params has the same effect
as setting parameters using the __init__ method.
The easiest and recommended way to accomplish this is to
not do any parameter validation in ``__init__``.
All logic behind estimator parameters,
like translating string arguments into functions, should be done in fit.

For using grid_search.GridSearch or any functionality of the
cross_validation module, an estimator must support the base.clone
function to replicate an estimator.
This can be done by providing a get_params method.
If get_params is present, then clone(estimator) will be an instance of
type(estimator) on which set_params has been called with clones of
the result of estimator.get_params().

Objects that do not provide this method will be deep-copied
(using the Python standard function copy.deepcopy)
if safe=False is passed to clone.

For an estimator to be usable together with pipeline.Pipeline in any but the
last step, it needs to provide a fit or fit_transform function.
To be able to evaluate the pipeline on any data but the training set,
it also needs to provide a transform function.
There are no special requirements for the last step in a pipeline, except that
it has a fit function. All fit and fit_transform functions must
take arguments X,y, even if y is not used.

Classifiers should accept y (target) arguments to fit
that are sequences (lists, arrays) of either strings or integers.
They should not assume that the class labels
are a contiguous range of integers;
instead, they should store a list of classes
in a classes_ attribute or property.
The order of class labels in this attribute
should match the order in which predict_proba, predict_log_proba
and decision_function return their values.
The easiest way to achieve this is to put:

self.classes_,y=np.unique(y,return_inverse=True)

in fit.
This return a new y that contains class indexes, rather than labels,
in the range [0, n_classes).

A classifier’s predict method should return
arrays containing class labels from classes_.
In a classifier that implements decision_function,
this can be achieved with:

In linear models, coefficients are stored in an array called coef_,
and the independent term is stored in intercept_.
sklearn.linear_model.base contains a few base classes and mixins
that implement common linear model patterns.

The sklearn.utils.multiclass module contains useful functions
for working with multiclass and multilabel problems.