<br><br><div class="gmail_quote">On Thu, Mar 20, 2008 at 3:09 PM, &quot;Martin v. L÷wis&quot; &lt;<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">&gt; Now, it is quite possible to say that this isn&#39;t desirable, and that<br>
&gt; 2.6 and 3.0 should not be able to run the same code at all, even if<br>
&gt; that was possible, but I haven&#39;t heard that opinion, and hope it isn&#39;t<br>
&gt; common.<br>
&gt;<br>
&gt; If we need to have this discussion again, I will prepare a longer<br>
&gt; answer to why the 2to3 conversion should be supplemented with a<br>
&gt; possible gradual code path. I started to write an answer already, but<br>
&gt; it&#39;s going to take me a while, and I&#39;d rather not. :)<br>
<br>
</div>That would be wasteful, indeed.<br>
<br>
Few people think that 3k should actively, aggressively, deliberately<br>
break 2.x code.<br>
<br>
However, it is decided and has been carved into stone that 3k must<br>
not include any transitional features that serve no other purpose<br>
but to allow running 2.x code. Therefore, you won&#39;t get u&#39;text&#39; as<br>
an alternative for &#39;text&#39;, and you won&#39;t get a &#39;unicode&#39; builtin.<br>
All the transitional mechanisms either get into 2.x, or 2to3, or not<br>
implemented at all.<br>
</blockquote><div><br>Will python 2.6 have something like &quot;from future import unicode_string_literals&quot; ?<br>This should also solve lennart&#39;s problem. (But then py3k would need to support that future import, which <br>
is forbidden).<br><br></div></div>