On Thu, 7 Apr 2016 at 08:58 Chris Angelico <rosuav@gmail.com> wrote:
On Fri, Apr 8, 2016 at 1:43 AM, Ethan Furman <ethan@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.