On Mon, Apr 6, 2020 at 9:49 AM Chris Angelico <[email protected]> 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
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/GVCPW2XMG5ORMKLCYHBFK7K3RDYNR742/
Code of Conduct: http://python.org/psf/codeofconduct/
