[Python-ideas] Draft2 PEP on string interpolation

[Andrew Barnert]

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?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150827/1431ac07/attachment-0001.html>