Thanks for this. Much appreciated.

do we want this for the release?

I would like it if it's close enough: it avoids people complaining when less reliable servers break.

Before we merge, one of the problem with logging is that it does not have the same behaviour with python 2.7 and python 3 (I was not aware of that I have to say or maybe I forgot):

import logging

logger = logging.getLogger('logger')
logger.warn('warning')

Python 2.7:

No handlers could be found for logger "logger"

Python 3:

warning

For this PR in particular that means that on Python 2.7 no messages will be printed about the datasets being downloaded.

Here is what I propose (after a quick chat with @ogrisel):

• we keep using logging in datasets
• we add a logger in sklearn/__init__.py with level logging.INFO. The reason for this is that I would not categorize a dataset being downloaded as a warning. The only reason we use logger.warning is that we want the message to be visible by the user and that the default logging level is logging.WARNING.

Note logging is only used in sklearn/datasets (and a few examples) I'll push a commit in this branch and then people can complain if they feel like it.

is there a way to make the handler only apply to logging emitted by scikit-learn?

This is already the case:

logger = logging.getLogger(__name__)

is only used by sklearn components (__name__ is "sklearn" in the above snippet).

is there a way to make the handler only apply to logging emitted by scikit-learn?

I think this is going to have this behaviour as long as we use logger = logging.getLogger(__name__) consistently. If we configure the handler in sklearn/__init__.py the logger called sklearn will have its handlers configured correctly (a StreamHandler + a logging.INFO level). A logger in a scikit-learn module will be called something like sklearn.subpackage.module. Because logging works in a hierarchical way it will end-up using the sklearn logger.

Not sure whether it is entirely necessary but 5d040fc may need to be backported in 0.19.X (Add download_if_missing argument to fetch_20newsgroups_vectorized)

Happy to merge now and then I'll go through all the necessary backports.

Merged, will do the backport to 0.19.X.

Cool, though I think it'd be good to do a final pass to see if everything is backported that we want.
Do you think we should do another RC or just release? We never released the RC conda-forge package...
I think I'm leaning towards "just release", we can always do 0.19.1. @jnothman ?

Though an issue in scikit-optimize kinda points toward re-thinking the decision of making _y_train_mean in GaussianProcessRegressor private :-/

+1 for just release but I will have to have a look at the pickling error of scikit-optimize/scikit-optimize#461.