<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Aug 21, 2016 at 12:28 AM Alexander Heger <<a href="mailto:python@2sn.net">python@2sn.net</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Did I leave anything out?</div><div>How would you weigh the benefits against the problems?</div><div>How would you manage the upgrade path for code that's been broken?</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>FIrst one needs to add the extension string attributes like split()/split(''), chars(), and substring[] (Python 3.7).  </div><div><br></div><div>When indexing becomes disallowed (Python 3.10 / 4.0) attempts to iterate (or slice) will raise TypeError.  The fixes overall will be a lot easier and obvious than introduction of unicode as default string type in Python 3.0.  It could already be used/test starting with Python 3.7 using 'from future import __monolythic_strings__`.</div></div></div></div><br></blockquote><div> Is there any equivalent __future__ import with such deep semantic implications? Most imports I can think of are mainly syntactic.</div><div>And what would it do? change the type of string literals? change the behavior of str methods locally in this module? globally? How will this play with 3rd party libraries?</div><div>Sounds like it will break stuff in a way that cannot be locally fixed.</div><div><br></div><div>~Elazar</div><div><br></div></div></div>