<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 27, 2015 at 12:13 PM, Andrew Barnert <span dir="ltr"><<a href="mailto:abarnert@yahoo.com" target="_blank">abarnert@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div>On Aug 27, 2015, at 11:27, Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:</div><div><br></div><blockquote type="cite">I also don't understand the claim that no str(estr) is necessary to render the result -- the estr implementation given at <a href="https://bitbucket.org/mixmastamyk/docs/src/default/pep/estring_demo.py" target="_blank">https://bitbucket.org/mixmastamyk/docs/src/default/pep/estring_demo.py</a> 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.)</blockquote><br></span><div>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.</div><div><br></div><div>(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?)</div></div></blockquote></div><br></div><div class="gmail_extra">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).<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>