Deprecate is_string_like

[anntzer]

This issue is similar to #7795 ("is_numlike should be deprecated and replaced by the correct isinstance calls"): cbook.is_string_like returns True for 0-dimensional masked arrays of string dtype (but not regular arrays...), but testing for is_string_like is often followed by calling of string methods (.lower(), etc.) on the object, or passing the object to, say, open() -- neither of which work with masked arrays of string dtype. (check yourself with git grep -A2 'is_string_like(')

In other words the actual semantics of the function simply do not match how it is used.

Most of these calls should probably be replaced by isinstance(obj, six.string_types) (possibly isinstance(obj, (six.string_types, six.binary_type)) depending on the case), which is much more explicit.

[tacaswell]

Why is 'isinstance' checking better than improving the duck typing?

[anntzer]

Because I doubt you will ever be able to make it possible to pass 0d-masked-arrays to open(), and that it'll at least take a while before masked string arrays implement string methods (as methods, not as standalone functions), if they ever do (which I doubt).

[dopplershift]

Isn't the purpose of having a is_string_like function the ability to abstract away the way we're doing the check (i.e. duck-typing vs. isinstance)?

[anntzer]

open doesn't care about abstraction. It exactly wants a string, or a string subclass.
Likewise, calling string methods (via method syntax) doesn't work on numpy arrays of string dtype, so the abstraction is not very good.

[dopplershift]

Do we really have no uses of is_string_like that could actually us a duck string?

[anntzer]

There may well be some -- but my guess is (and a quick grep suggests) that they are a minority, so I'd suggest looking at them and asking whether we really need to support them (note that as mentioned above, so far numpy 0d arrays of string dtype were actually rejected, only 0d masked arrays of string dtype were accepted, and no one seemed to complain.)

I did just realize that indexing numpy string arrays returns a np.str_, which is a different type, but similarly to the is_numlike case, one can just define string_like = (str, np.str_) and then use isinstance(obj, string_like) (yes, this could even be the new implemetation of is_string_like if you want to keep it...).

[anntzer]

Closed by #8011.