<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 7 Apr 2016 at 08:58 Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Apr 8, 2016 at 1:43 AM, Ethan Furman <<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>> wrote:<br>
> The problem with that is that Paths are conceptually not strings, they just<br>
> serialize to strings, and we have a lot of infrastructure in place to deal<br>
> with that serialized form.<br>
><br>
> Is there anything, anywhere in the Python ecosystem, that would also benefit<br>
> from something like an __as_str__ method/attribute?<br>
<br>
I'd like to see this used in 2/3 compatibility code. You can make an<br>
Ascii class which subclasses bytes, but can be treated as<br>
str-compatible in both versions. By restricting its contents to<br>
[0,128) it can easily be "safe" in both byte and text contexts, and<br>
it'll cover 99%+ of use cases. So if you try to getattr(x,<br>
Ascii("foo")), it'll work fine in Py2 (because Ascii is a subclass of<br>
str) and in Py3 (because Ascii.__tostring__ returns a valid string),<br>
and there's a guarantee that it'll behave the same way (because the<br>
string must be ASCII-only).<br></blockquote><div><br></div><div>But couldn't you also just define a str subclass that checks its argument(s) are only valid ASCII values? What you're proposing is to potentially change all places that operate with a string to now check for a special method which would be a costly change potentially to performance as well as propagating this concept everywhere a string-like object is expected.</div><div><br></div><div>I think it's important to realize that the main reason we are considering this special method concept is to make it easier to introduce in third-party code which doesn't have pathlib or for people who don't want to import pathlib just to convert a pathlib.PurePath object to a string. Otherwise we would simply have pathlib.fspath() or something that checked if its argument was a subclass of pathlib.PurePath and if so call str() on it, else double-check that argument was an instance of str and keep it simple. But instead we are trying to do the practical thing and come up with a common method name that people can be sure will exist on pathlib.PurePath and any other third-party path library. I think trying to generalize to "string-like but not __str__()" is a premature optimization that has not exposed enough use-cases to warrant such a deep change to the language.</div></div></div>