<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 7 Apr 2016 at 11:29 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 3:31 AM, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>
> But couldn't you also just define a str subclass that checks its argument(s)<br>
> are only valid ASCII values? What you're proposing is to potentially change<br>
> all places that operate with a string to now check for a special method<br>
> which would be a costly change potentially to performance as well as<br>
> propagating this concept everywhere a string-like object is expected.<br>
<br>
Fair enough. That was a spur-of-the-moment thought. To be honest, this<br>
proposal is a massive generalization from, ultimately, a single<br>
use-case.<br>
<br>
> I think it's important to realize that the main reason we are considering<br>
> this special method concept is to make it easier to introduce in third-party<br>
> code which doesn't have pathlib or for people who don't want to import<br>
> pathlib just to convert a pathlib.PurePath object to a string.<br>
<br>
And this should make it easier for third-party code to be functional<br>
without even being aware of the Path object. There are two basic<br>
things that code will be doing with paths: passing them unchanged to<br>
standard library functions (eg open()), and combining them with<br>
strings. The first will work by definition; the second will if paths<br>
can implicitly upcast to strings.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In contrast, a function or method to convert a path to a string<br>
requires conscious effort on the part of any function that needs to do<br>
such manipulation, which correspondingly means version compatibility<br>
checks.</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Libraries will need to release a new version that's<br>
path-compatible, even though they don't actually gain any<br>
functionality.<br></blockquote><div><br></div><div>But they will with yours as well. At best you could get this into Python 3.6 and then propagate this implicit string-like conversion functionality throughout the language and stdlib, but any implicitness won't be backported either as it's implicit. So while you're saying you don't like the explicitness required to backport this, your solution doesn't help with that either as you will still need to do the exact same method lookup for any code that wants to work pre-3.6. And if using path objects takes off and new APIs come up that don't take a string for paths, then the explicit conversion can be left out -- and perhaps removed in converted APIs -- while your implicit conversion will forever be baked into Python itself.</div></div></div>