lightning is using the following utils:
- check_random_state
- safe_sparse_dot
- shuffle
- safe_mask
- sklearn.utils.testing.*
The latter is not big deal but I like importing assertions from the same
place.
On a second thought, importing all public utils in __init__.py might
quickly become messy.
I like Andy's propsal of having no imports at all in __init__.py.
I suggest we move everything in __init__.py to a suitable submodule.
For the utils which we make private, I suggest we make a deprecation cycle
for safety.
A lot of utils will likely become private so we could use a decorator
@deprecated_util to automate the task.
Mathieu
On Sat, Sep 13, 2014 at 11:22 AM, Mathieu Blondel <math...@mblondel.org>
wrote:
> We should survey what other packages use. I'll have a look at what
> lightning uses later.
>
> Mathieu
>
> On Sat, Sep 13, 2014 at 2:23 AM, Andy <t3k...@gmail.com> wrote:
>
>> +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> 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
>> listScikit-learn-general@lists.sourceforge.nethttps://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
