>
> 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):
try:
for i in x:
f(i)
except:
print(x)
f((1,2,3))
f(('house', 'car', 'cup'))
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
