[Python-ideas] Draft2 PEP on string interpolation

[Guido van Rossum]

On Thu, Aug 27, 2015 at 12:13 PM, Andrew Barnert <abarnert at yahoo.com> wrote:

> On Aug 27, 2015, at 11:27, Guido van Rossum <guido at python.org> wrote:
>
> I also don't understand the claim that no str(estr) is necessary to render
> the result -- the estr implementation given at
> https://bitbucket.org/mixmastamyk/docs/src/default/pep/estring_demo.py
> has a __str__ method that renders the .rendered attribute, but without the
> str() call the type of 'a' in the above examples would not be str, and
> various things that operate on strings (e.g. regular expression searches)
> would not work. A solution might be to make estr a subclass of str, but
> nothing in the PEP suggests that you have even considered this problem.
> (The only hint I can find is the comment "more magic-methods to be
> implemented here, to improve str compatibility" in your demo
> implementation, but without subclassing str this is not enough.)
>
>
> Even subclassing str doesn't really help, because there's plenty of code
> (including, I believe, regex searches) that just looks at the raw string
> storage that gets created at str.__new__ and can never be mutated or
> replaced later. So, anything that's delayed-rendered is not a str, or at
> least it's not the right str.
>
> (I know someone earlier in the discussion suggested that at the C level
> you could replace PyUnicode_READY with a function that, if it's an estr,
> first calls self.__str__ and then initializes the string storage to the
> result and then does the normal READY stuff, but I don't think that
> actually works, does it?)
>

I think subclassing would be enough -- the raw string should be the default
rendered string (not the template), and any code that wants to do something
*different* will have to extract the template and the list of values (and
whatever else is extracted) from other attributes. (Note that it shouldn't
be *necessary* to store anything besides the template and the list of
values, since the rest of the info can be recovered by parsing the
template. But might be *convenient* to store some other things, like the
actual text of the expression that produced each value, and the format spec
(or perhaps integers into the template that let you find these -- the
details would be up to the implementer and a matter of QoI).

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150827/fe53f644/attachment.html>