Thank you for your PR.

Are you sure this wasn't fixed in #7064 ? If so please add a unit test (or extend test_unicode_kernel) that would fail on master but pass with this PR. Thanks.

you're mixing tabs and spaces. Please use spaces.
(also there's a weird issue in the test for tabs vs spaces?!)
Why is this necessary? It's not done in predict or in the sparse case. And in fitting it's only done in the dense case in _dense_fit, right?

Thanks for your responses!

@rth The code from the issue #7064 is the same but this was not applied to the predict_proba endpoint. I have also now added a call to predict_proba in the unit tests - this will fail on master.

@amueller My bad, I have fixed the spacing! It is necessary to catch unicode objects that are given to the kernel parameter which are not handled by libSVM. Other parameters are not sensitive to this and neither should kernel be. It is only necessary for the _dense_predict_proba also

worry less about lgtm and more about travis ;)

Why is this not necessary in the sparse case?

@amueller haha okay I'll focus on travis first.

As for why this isn't necessary in the sparse case, the kernel is specified by its index in the sparse case which seems not to be sensitive to this...
_sparse_predict: kernel_type = self._sparse_kernels.index(kernel)

I've tested and indeed, the sparse versions do not error.

    # The order of these must match the integer values in LibSVM.
    # XXX These are actually the same in the dense case. Need to factor
    # this out.
    _sparse_kernels = ["linear", "poly", "rbf", "sigmoid", "precomputed"]

Maybe we should just do that? It's weird to have substantially different code paths for sparse and dense. If you'd rather not get involved in this, that's fine, too ;)

Basically we just need to move kernel_index = LIBSVM_KERNEL_TYPES.index(kernel) from the cython code to the python code in the dense case, then it'll be the same as the sparse case, we can rename _sparse_kernels to _kernels and can get rid of the string handling code and just pass integers to cython everywhere.

It is still in progress?

@qmick Feel free to take it if @JoshuaMeyers doesn't reply after some time. Note that we are using multiple ways to handle the problem currently.
(1)in sparse case : passing int kernel_type instead of str kernel
(2)in some functions in dense case(e.g., predict): passing kernel instead of str kernel
(3)in some functions in dense case(e.g., fit): using str to cast kernel to string before passing
I agree with amueller's comment above (i.e., always use the first way).

@qinhanmin2014 Thanks, I'll keep looking at it.

Hey @qmick, feel free to have a go at this. I haven't had the time. Apologies!

Thanks @JoshuaMeyers for your great work so far :)

This issue was addressed by #10412. Closing this MR.