<p dir="ltr">Why strings and not, say, floats or bools or lists or bytes? Is it because strings have a uniquely compelling use case, or...?</p>
<p dir="ltr">(For context from the numpy side of things, since IIUC numpy's fixed-width integer types were the impetus for __index__: numpy actually has a shadow type system that has versions of all of those types above except list. It also has a general conversion/casting system with a concept of different levels of safety, so for us __index__ is like a "safe" cast to int, and __int__ is like a "unsafe", and we have versions of this for all pairs of internal types, which if you care about this in general then having a single parametrized concept of safe casting might make more sense then adding new methods one by one.</p>
<p dir="ltr">I'm not aware of any particular pain points triggered by numpy's strings not being real strings, though, at least in numpy's current design.)</p>
<p dir="ltr">-n</p>
<div class="gmail_quote">On Apr 7, 2016 6:05 AM, "Chris Angelico" <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is a spin-off from the __fspath__ discussion on python-dev, in<br>
which a few people said that a more general approach would be better.<br>
<br>
Proposal: Objects should be allowed to declare that they are<br>
"string-like" by creating a dunder method (analogously to __index__<br>
for integers) which implies a loss-less conversion to str.<br>
<br>
This could supersede the __fspath__ "give me the string for this path"<br>
protocol, or could stand in parallel with it.<br>
<br>
Obviously str will have this dunder method, returning self. Most other<br>
core types (notably 'object') will not define it. Absence of this<br>
method implies that the object cannot be treated as a string.<br>
<br>
String methods will be defined as accepting string-like objects. For<br>
instance, "hello"+foo will succeed if foo is string-like.<br>
<br>
Downside: Two string-like objects may behave unexpectedly - foo+bar<br>
will concatenate strings if either is an actual string, but if both<br>
are other string-like objects, depends on the implementation of those<br>
objects.<br>
<br>
Bikeshedding:<br>
<br>
1) What should the dunder method be named? __str_coerce__? __stringlike__?<br>
<br>
2) Which standard types are sufficiently string-like to be used thus?<br>
<br>
3) Should there be a bytes equivalent?<br>
<br>
4) Should there be a format string "coerce to str"? "{}".format(x) is<br>
equivalent to str(x), but it might be nice to be able to assert that<br>
something's stringish already.<br>
<br>
Open season!<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div>