It isn't so much that strings are special, it's that lists and tuples are special. Very few iterables can be directly converted to Numpy arrays. Try `np.array({1,2})` and you get `array({1, 2}, dtype=object)`, a 0-dimensional array.

there is no representation for sets as unordered data as in Numpy all is ordered

> But it does deal with strings as monolithic objects,

Seems to me that Numpy treats strings as "I, uh, don't really know what you want me to do with this" objects. That kinda makes sense for Numpy, because, uh, what DO you want Numpy to do with strings?

if it was an iterable, convert to an array length-one characters

Numpy is NOT designed to mess around with strings, and Numpy does NOT have as high a proportion of programmers using it for strings, so Numpy does not have much insight into what's good and what's useful for programmers who need to mess around with strings.

sometimes arrays of string-like objects are needed. 

In summary, Numpy isn't a good example of "strings done right, through more experience", because they are barely "done" at all.

> doing away with many of the pitfalls of strings in Python.

Please start listing the pitfalls, and show how alternatives will be an improvement.

The question is about determination of iterable objects.  This has been discussed many times on this list.

def f(x):
        for i in x:

f(('house', 'car', 'cup'))