<br><br><div class="gmail_quote">On Thu, Mar 20, 2008 at 3:09 PM, "Martin v. Löwis" <<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>> 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">> Now, it is quite possible to say that this isn't desirable, and that<br>
> 2.6 and 3.0 should not be able to run the same code at all, even if<br>
> that was possible, but I haven't heard that opinion, and hope it isn't<br>
> common.<br>
><br>
> If we need to have this discussion again, I will prepare a longer<br>
> answer to why the 2to3 conversion should be supplemented with a<br>
> possible gradual code path. I started to write an answer already, but<br>
> it's going to take me a while, and I'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't get u'text' as<br>
an alternative for 'text', and you won't get a 'unicode' 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 "from future import unicode_string_literals" ?<br>This should also solve lennart's problem. (But then py3k would need to support that future import, which <br>
is forbidden).<br><br></div></div>