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

Chris Angelico rosuav at gmail.com
Thu Apr 7 13:02:30 EDT 2016


On Fri, Apr 8, 2016 at 2:31 AM, Random832 <random832 at fastmail.com> wrote:
> On Thu, Apr 7, 2016, at 12:11, Paul Moore wrote:
>> OK, that makes sense. But when you say "it'll work fine in Python 3"
>> how will that happen? What code needs to call __fromstring__ to make
>> this happen? You mention getattr. Would you expect every builtin and
>> stdlib function that takes a string to be modified to try
>> __fromstring__? That sounds like a pretty big performance hit, as
>> strings are very critical to the interpreter.
>
> Isn't it only a performance hit on something that's an exception now?
> Like, if PyString_Check fails, then call it.

I like this idea; it can be supported by a very small semantic change,
namely that this method is not guaranteed to be called on strings or
subclasses of strings. For cross-implementation compatibility, I would
require that str.__name_needed__() return self, and that well-behaved
subclasses not override this; that way, there's no semantic
difference. Consider this like the "x is y implies x == y"
optimization that crops up here and there; while it's legal to have
x.__eq__(x) return False (eg NaN), there are some places where it's
assumed to be found anyway (or, to be technically correct, where
something looks for "x is y or x == y" rather than simply "x == y").
So this would be "self if isinstance(self, str) else
self.__thingy__()".

Deep inside CPython, it would simply be failure-mode handling: instead
of directly raising TypeError, attempt a treat-as-string conversion,
which will raise TypeError if it's not possible. A cursory inspection
of the code suggests that the only place that needs to changed is
PyUnicode_FromObject in unicodeobject.c. It currently checks if the
object is exactly an instance of PyUnicode (aka 'str'), then for a
subclass of same, then raises TypeError "Can't convert '%.100s' object
to str implicitly". Even the wording of that message leaves it open to
more types being implicitly convertible; the only change here is that
you can make your type convertible without actually subclassing str.

ChrisA

ChrisA


More information about the Python-ideas mailing list