On Mon, Apr 6, 2020 at 9:49 AM Chris Angelico <rosuav@gmail.com> wrote:
This all made me think *why* do I type check strings, and virtually nothing else? And it's because in most otehr places, if I want a given type, I can just try to make it from the input:
x = float(x) i = int(i)
arr = np.asarray(np)
but:
st = str(st)
doesn't work because ANY object can be made into a string.
Not sure I understand your point here. Calling float() or int() will give you a float or int for many values that aren't floats or ints, just as calling str() will give you a string. The only real difference (as far as I can tell) is that, as you say, any object can be stringified. But all of those operations are potentially lossy - int(1.5) and float(1e100000) both throw away information - and they don't prove that something already was a string/int/float, just that it _now_ is.
yes, but the operation will only work if the value CAN be turned into a float or int (or numpy array, for asarray), and you will get a ValueError for most arbitrary objects. It doesn't have to be lossless to be useful -- you are most often going to lose SOMETHING when you do a type cast. This was particularly useful in Py2 without future division: def fun(x): x = float(x) .... meant that you were assured that x was indeed a float now, and whatever type it was before, it was a type (and value) that could be cast to a float. even it were lossy, And now, I still use that when receiving a string (Or something :-) ) that should be convertible to a float, if someone passes in some other type, or a string that can't be interpreted as a float, I get a TypeError or ValueError. But with str(), virtually any type (absolutely any?) will lead to a valid string object, regardless of its type or value. In practice, the only example I can think of is maybe Path objects, which you may want to accept in place of a str, in a function that really does need a str. but we have the __fspath__protocol now, so that's been obsoleted. and as pointed out in this thread, there is a lot of code that requires an actual str object, not just something that is duck typed like one. This is a lot like numpy, and why asarray is used a lot. but no, asstring() would not be useful -- but mostly because there are essentially no other types out there that are "string-like objects". -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython