For completness, here are some similar tuples:

• SPARSE_TYPES
• INTEGER_TYPES
• externals.six.string_types

Shall we agree in lower/upper case ?

Hijacking since its also relevant to an open PR I have #10042 and @jnothman sent me to #7394 (which this is the successor of right?)
It would probably fit into the utils folder. Maybe create a types.py? Also would this require scikit-wide changes or just starting to use this from now on when type-checking is required?

Shall we agree in lower/upper case ?

Uppercase were used since it was global at that time. If we define something, I would use lower case.

For completness, here are some similar tuples:

You also have FLOAT_DTYPE in validation.py

I would suggest to define it inside validation.py or in __init__.py I think but I would rely on the experience of @lesteve @jnothman @amueller

Also important for the matter, should 0d arrays be considered as ints for all pratical purposes (and be included in the int types)? It seems scikit is still inconsistent in this aspect.

@glemaitre regarding FLOAT_DTYPES I don't think it can be substituted by floating_types since it is used with check_array which expects a tuple of types and converts to the first type when there's no match (see here).

maybe an option is to set floating_types to np.float64, float, np.floating) but I'm not sure that this is the right move.

Actually there are no many places where isinstance is used with floating apart from validation.py. So I think that we can let it as it is.

maybe an option is to set floating_types to np.float64, float, np.floating) but I'm not sure that this is the right move.

Actually it should be equivalent to floating_types=(np.float64, float, np.float32, np.float16)

Actually, np.floating also has float128 and float8 which might not be desirable in check_array in the same manner that we might not want to fit float (the non numpy value) to check_array.

So at the moment this doesn't handle 0d arrays. Are we making that a policy?

It doesn't. I kept the behavior that was on the codebase. IMHO if a function needs to accept 0d arrays it should be handled there directly (in the same manner that None is handled). By something like:

def my_func (param=None):
       if not ( isinstance(param, integer_types) or param is None):
              if param.ndim == 0 and isinstance(param[()], integer_types):
                   param = param[()]
              else
                   raise ValueError("n_estimators must be an integer, got {0}.".format(type(param)))	
    ...

I think we have previously had issues where 0d arrays were passed in unknowingly, but it may have been due to bugs in numpy/scipy/etc that previously existed (e.g. iteration over memmapped array or something obscure like that).

And answering to @jnothman I'm +1 to not explicitly support 0d arrays. @glemaitre any thoughts ?

0d arrays were not supported, I don't we should try to add support. It would make the code overly complex for no real benefits.

I don't think the code becomes overly complex if we have an is_integer or a check_integer helper instead of using isinstance.

Yes, 0d arrays were not supported, but this could also be inducing unintentional behaviour. Note that, for instance, 0d arrays are output when iterating over a numpy array. Thus for instance ParameterGrid({'min_weight_fraction_leaf': np.linspace(.1, 1), 'max_depth': np.arange(2, 10, 2)}) will set parameters to numpy 0d arrays, not to Python scalars. (Perhaps this is a bug in ParameterGrid, but it's certainly longstanding.) Using if isinstance(my_param, integer_type): do something; else: do some other thing will do the other - unwanted - thing. Not supporting 0d arrays means we need to test our code better and make sure we never use else in validation and always use elif. Are you still sure there are no real benefits?

If that's the case, I think we should implement our own checker (or validation unwrapping the 0d array).

>>> foo = np.array(42)
>>> isinstance(foo, (numbers.Integral, np.integer))
False
>>> isinstance(foo[()], (numbers.Integral, np.integer))
True

and adding np.ndarray to the possible types defeats the purpose.

@jnothman ParameterGrid returns instances of np.integer or np.float that are scalar classes, but no instances of 0d arrays:

>>> import numbers
>>> import numpy as np
>>> from sklearn.model_selection import ParameterGrid

>>> [isinstance(d['a'], (numbers.Integral, np.integer))
...  for d in ParameterGrid(dict(a=np.arange(3)))]
...
[True, True, True]
>>> [isinstance(d['a'], np.ndarray) for d in ParameterGrid(dict(a=np.arange(3)))]
[False, False, False]

I had not realized that instances of np.int64 had a ndim and a shape attribute either. I agree we should be careful to test that what we get out of ParameterGrid iterations is compatible with the set_params and constructors of estimators. I don't know if it's possible to write a test_common. Python 3 type hints would helpful for this.

0d arrays were not supported, I don't we should try to add support. It would make the code overly complex for no real benefits.

I agree with that. 0d array is a weird quirk which to be honest I don't really understand. They should not be confused with numpy scalars.

arr_0d = np.array(0)  # 0d array
scalar = np.int64(0)  # numpy scalar

We should definitly support numpy scalars because they are very easy to get, e.g. by indexing, doing reduction like .max(), .sum(), iterating over an array, etc ...
Numpy 0d arrays I am not sure how you would get one without doing explicitly something like np.array(0).

Also note that in recent versions of numpy: issubclass(np.integer, numbers.Integral) is True but this is not the case in numpy 1.8.2 which we still support. So it's worth maintaining a SCALAR_INTEGER_TYPES = (numbers.Integral, np.integer) constant in sklearn.utils.fixes for the time being.

There's also another integer_types in six. Here:

which is only used these two tests, but I'm not sure that it has the same functionality:

Just to not lose this comment within the review
@ogrisel I disagree with the scalar_real_types. Since integers derive from real whereas they do not derive from float.

>>> import numbers
>>> isinstance(int(42), numbers.Real)
True
>>> isinstance(int(42), float)
False

Do not modify the vendored six module but fill tree to replace usage of six.integer_types by your own constants from sklearn.utils.fixes instead.

@ogrisel I disagree with the scalar_real_types. Since integers derive from real whereas they do not derive from float.

Indeed, good catch. SCALAR_FLOATING_TYPES then.

There are places where only numbers.Integral is used like:

which can raise an error if numpy is 1.8.2. But there's no open issue in that. Shall we make it homogeneous and add a test for it?

Another disturbing thought is this comment

>>> np.__version__
'1.8.2'
>>> types = (np.int0, np.int8, np.int16, np.int32, np.int64)
>>> [issubclass(t, numbers.Integral) for t in types]
[False, False, False, False, False]

.... 

>>> np.__version__
'1.9.3'
>>> types = (np.int0, np.int8, np.int16, np.int32, np.int64)
>>> [issubclass(t, numbers.Integral) for t in types]
[True, True, True, True, True]

...

>>> np.__version__
'1.10.4'
>>> types = (np.int0, np.int8, np.int16, np.int32, np.int64)
>>> [issubclass(t, numbers.Integral) for t in types]
[True, True, True, True, True]

...

>>> np.__version__
'1.11.3'
>>> types = (np.int0, np.int8, np.int16, np.int32, np.int64)
>>> [issubclass(t, numbers.Integral) for t in types]
[True, True, True, True, True]

...

>>> np.__version__
'1.12.1'
>>> types = (np.int0, np.int8, np.int16, np.int32, np.int64)
>>> [issubclass(t, numbers.Integral) for t in types]
[True, True, True, True, True]

Also note that in recent versions of numpy: issubclass(np.integer, numbers.Integral) is True but this is not the case in numpy 1.8.2 which we still support. So it's worth maintaining a SCALAR_INTEGER_TYPES

Since currently the minimal numpy version is 1.11.0 a significant part of this PR is no longer needed (and was fixed in #14004)

This was taken care by #14004, but some were left off

~/code/scikit-learn master
(mne) ❯ git grep -i 'np.asarray(test_size)'                             
sklearn/model_selection/_split.py:    test_size_type = np.asarray(test_size).dtype.kind

I'll close this one and maybe open a new one