[Python-ideas] Dunder method to make object str-like

[Brett Cannon]

On Thu, 7 Apr 2016 at 11:29 Chris Angelico <rosuav at gmail.com> wrote:

> On Fri, Apr 8, 2016 at 3:31 AM, Brett Cannon <brett at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160407/9c8407bc/attachment-0001.html>