<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Thu, Nov 9, 2017 at 9:51 PM, Guido van Rossum </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">If we have to change the name I'd vote for string_annotations -- "lazy" has too many other connotations (e.g. it might cause people to think it's the thunks). I find str_annotations too abbreviated, and stringify_annotations is too hard to spell.<br><div class="gmail_extra"><br></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​I can't say I disagree. ​And maybe importing string_annotations from the __future__ doesn't sound quite as sad as importing something from the __past__.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Anyway, it's not obvious to me that it is the module author that should decide how the annotations are handled. See also this quote below:</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">(Quoted from the end of </div><div class="gmail_default" style="font-family:monospace,monospace"><a href="https://mail.python.org/pipermail/python-ideas/2017-October/047311.html">https://mail.python.org/pipermail/python-ideas/2017-October/047311.html</a> )<br class="gmail-Apple-interchange-newline"><br style="font-family:arial,sans-serif"><div class="gmail_quote" style="font-family:arial,sans-serif">On Thu, Oct 12, 2017 at 3:59 PM, Koos Zevenhoven <span dir="ltr"><<a href="mailto:k7hoven@gmail.com" target="_blank">k7hoven@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail-"><div style="font-family:monospace,monospace"><br></div></span><div class="gmail_extra"><div><div style="font-family:monospace,monospace">​​[*] Maybe somehow make the existing functionality a phantom easter egg––a blast from the past which you can import and use, but which is otherwise invisible :-). Then later give warnings and finally remove it completely.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">But we need better smooth upgrade paths anyway, maybe something like:</div><div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">from __compat__ import unintuitive_decimal_contexts</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">with unintuitive_decimal_contexts:</div><div style="font-family:monospace,monospace">    do_stuff()</div><br></div><div><div style="font-family:monospace,monospace">​Now code bases can more quickly switch to new python versions and make the occasional compatibility adjustments more lazily, while already benefiting from other new language features. </div></div><span class="gmail-HOEnZb"><font color="#888888"><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">––Koos​</div><br></font></span></div><span class="gmail-"><div><br></div></span></div></div></blockquote><div> </div></div></div></div></div>-- <br><div class="gmail-m_4566789279196901374m_5564610618383969404gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>