I don't think we need the float cast here...

Do we need to test for positive alphas which are float. I think that we already are doing so in all the tests, isn't it?

I would separate the tests for negative alphas since that they should raise error.
You can make a test called test_ridgecv_neg_alphas() with a parametrize pytest for the integer and floating type.

rename test_ridgecv_int_alphas

I would remove this comment since that it is obvious from the renaming from the function

put directly a list when instantiating: RidgeCV(alphas=[1, 10, 100]).
You could also make sure that a numpy array with integer is also converted. In this case use a parametrized test

@pytest.mark.parametrize(
     "alphas",
    [(np.array([1, 10, 100])),
     ([1, 10, 100])])
def test_ridge_cv_alphas(alphas):
    X = ...
    y = ...
    ridge = RidgeCV(alphas)
    ridge.fit(X, y)

The checking needs to be done outside from the loop. Otherwise we start to compute some stuff to actually break it at the end.

So something like:

if np.any(alphas < 0):
    raise ValueError("alphas cannot be negative. Got {} containing some negative value instead.")

you need to use assert_raises_regex to match the string

this is never executed.

I think you can remove this line and dedent the rest of this function

Great, I'm new to tests in python. Already fixed it.

I'm not actually sure what this is trying to test. Is it trying to test that the input is validated and turned into floats before fit? We don't usually do this, because the user may also set them with set_params.

I also don't think this is currently asserting that the alphas are floats, only that they are unchanged or equivalent.

And I think we have common tests which do that. I'm short, I don't think this test adds anything in its current form.

ok, I'll remove it, just put it as a suggestion from the other reviewer. At least I've learned how these tests work.

Please avoid introducing unnecessary and unrelated changes like this. It makes it hard to review your work, and may introduce merge conflicts for other changes in the works.

Usually we do not alter parameters in __init__, because they can also be set in other ways. We delay all validation until fit (except in old code)

my mistake, an error of the file. changed again

why did you remove this?

Oh, I see that this was already done in master. These days we would avoid such validation.

You seem to have removed some text from v0.20.rst, probably without realising. Please look at your diff and re-add the text you remove.

Please avoid changes that are not related to your PR. It makes the review less pleasant for everyone involved. Can you put back the lambdas?

I'm sorry, I don't know why this keeps happening. I had already reverted those changes.

What do you mean by this? negative integer -> integer since the bug is mainly about unexpected error when using integer alpha? (negative integer will be rejected right)

You're right, both integers raise error.

Try to get rid of this strange diff.

I don't know, the file in the master has already that line. Should I remove it?

If you actually don't change anything and find it hard to get rid of it, you might just keep it. (Hope there won't be some strange things when merging)

Why doing so?

I was suggested to make that changes a few lines above: to add a conversion in the __init__ and then remove the float. It's done in the init of _RidgeGCV.

I think this test is redundant. We don't need too much tests for such a minor issue.

I added that test because the initial error stated: ValueError: Integers to negative integer powers are not allowed. So I had to add a line to raise an error for negative alphas and in the tests I was testing it worked.

You don't persuade me here but I won't focus too much on that.
I just think such a minor thing doesn't deserve so many tests.