> 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