+1 of cleaning up __init__.py (maybe no implementations at all?)
+1 for making private methods start with underscore (which will break
everything ^^)
Also we need to add utils to the References then.
No idea how to decide what should be public and what not, though.
On 09/08/2014 04:01 PM, 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 <mailto: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
<mailto: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
------------------------------------------------------------------------------
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
