On Fri, Apr 8, 2016 at 3:31 AM, Brett Cannon <brett@python.org> wrote:
> 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.
Fair enough. That was a spur-of-the-moment thought. To be honest, this
proposal is a massive generalization from, ultimately, a single
use-case.
> 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.
And this should make it easier for third-party code to be functional
without even being aware of the Path object. There are two basic
things that code will be doing with paths: passing them unchanged to
standard library functions (eg open()), and combining them with
strings. The first will work by definition; the second will if paths
can implicitly upcast to strings.
In contrast, a function or method to convert a path to a string
requires conscious effort on the part of any function that needs to do
such manipulation, which correspondingly means version compatibility
checks.
Libraries will need to release a new version that's
path-compatible, even though they don't actually gain any
functionality.
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.