I agree with everything you said, Matthieu (which of course does not
answer the questions that you raise).

Gaël

On Mon, Sep 08, 2014 at 11:01:44PM +0900, Mathieu Blondel wrote:
> Maintaining backward compatibility for a subset of the utils only means that
> from now on we will have to decide whether an util deserves to be public or
> not. While we are at it, I would rather make it explicit and use an underscore
> prefix for private utils and no prefix for public utils.
> This can be combined with your proposal of importing all public utils
> in__init__.py but __init__.py will have to be cleaned up as it's kind of messy
> right now. One concern is that the usefulness of an util is very subjective. I
> would like also to argue that utils can be important for the consistency 
> across
> scikit-learn compatible projects. For example, the utils.validation module can
> be useful for doing validation in a consistent manner in all projects.

> Mathieu

> On Mon, Sep 8, 2014 at 10:00 PM, Gael Varoquaux 
> <gael.varoqu...@normalesup.org>
> wrote:

>     Hi people,

>     So far we have had no policy of backward compatibility in sklearn/utils.
>     However, some of the utilities there are very useful for packages that
>     want to extend scikit-learn's functionality, such as seqlearn,
>     sklearn-theano, nilearn...

>     The latest set of changes in the validation utilities have brought in a
>     great cleanup of these utilities. However as a result it has also broken
>     nilearn. This isn't a big deal, as nilearn isn't released, however I
>     think that we need to think about our backward compatibility strategy in
>     sklearn/utils.

>     Here is my proposal: we need to apply standard deprecation cycle for
>     everything in sklearn/utils/__init__.py and all the rest is off limits.

>     What do people think?

>     Gaël

>     
> ------------------------------------------------------------------------------
>     Want excitement?
>     Manually upgrade your production database.
>     When you want reliability, choose Perforce
>     Perforce version control. Predictably reliable.
>     http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/
>     ostg.clktrk
>     _______________________________________________
>     Scikit-learn-general mailing list
>     Scikit-learn-general@lists.sourceforge.net
>     https://lists.sourceforge.net/lists/listinfo/scikit-learn-general



> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk

> _______________________________________________
> Scikit-learn-general mailing list
> Scikit-learn-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scikit-learn-general


-- 
    Gael Varoquaux
    Researcher, INRIA Parietal
    Laboratoire de Neuro-Imagerie Assistee par Ordinateur
    NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France
    Phone:  ++ 33-1-69-08-79-68
    http://gael-varoquaux.info            http://twitter.com/GaelVaroquaux

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Scikit-learn-general mailing list
Scikit-learn-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general

Reply via email to