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

[Brett Cannon]

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

> On Fri, Apr 8, 2016 at 1:43 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
> > The problem with that is that Paths are conceptually not strings, they
> just
> > serialize to strings, and we have a lot of infrastructure in place to
> deal
> > with that serialized form.
> >
> > Is there anything, anywhere in the Python ecosystem, that would also
> benefit
> > from something like an __as_str__ method/attribute?
>
> I'd like to see this used in 2/3 compatibility code. You can make an
> Ascii class which subclasses bytes, but can be treated as
> str-compatible in both versions. By restricting its contents to
> [0,128) it can easily be "safe" in both byte and text contexts, and
> it'll cover 99%+ of use cases. So if you try to getattr(x,
> Ascii("foo")), it'll work fine in Py2 (because Ascii is a subclass of
> str) and in Py3 (because Ascii.__tostring__ returns a valid string),
> and there's a guarantee that it'll behave the same way (because the
> string must be ASCII-only).
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160407/8153460f/attachment-0001.html>