Repository navigation
Deprecate is_string_like #7835
Description
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.
Activity
tacaswell commentedon Jan 15, 2017
Why is 'isinstance' checking better than improving the duck typing?
anntzer commentedon Jan 15, 2017
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 commentedon Jan 16, 2017
Isn't the purpose of having a
is_string_likefunction the ability to abstract away the way we're doing the check (i.e. duck-typing vs.isinstance)?anntzer commentedon Jan 16, 2017
opendoesn'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 commentedon Jan 16, 2017
Do we really have no uses of
is_string_likethat could actually us a duck string?anntzer commentedon Jan 16, 2017
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 definestring_like = (str, np.str_)and then useisinstance(obj, string_like)(yes, this could even be the new implemetation ofis_string_likeif you want to keep it...).anntzer commentedon Apr 22, 2017
Closed by #8011.
`is_string_like` is deprecated (matplotlib#7835).
Fix use of is_string_like (which throws lots of
Pin matplotlib to 2.2.4 lts.