<br><br><div class="gmail_quote">On Sun, Mar 23, 2008 at 8:37 AM, Lennart Regebro <<a href="mailto:regebro@gmail.com" target="_blank">regebro@gmail.com</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;">
Eric Smith wrote:<br>
> It's not implementable because the work has to occur in ast.c (see<br>
> Py_UnicodeFlag). It can't occur later, because you need to skip the<br>
> encoding being done in parsestr(). But the __future__ import can only<br>
> be interpreted after the AST is built, at which time the encoding has<br>
> already been applied. There are some radical things you could do to<br>
> work around this, but it would be a gigantic change.<br>
<br>
Oh, <swear words>!<br>
</blockquote><div><br>I don't believe this to be true (we can simply store the source encoding information (which it might already be) and translate the *use* of string literals into unicode(literal, encoding).) But I still think this is a bad idea. Using the same codebase for 3.0 and 2.6 will leave you with inefficient and fragile code in one of the two codebases -- quite likely both. I know, I've tried. I don't see how it improves maintainability to leave your source full of forward- and backward-compatibility hacks. 3.0 was meant to be a clean break. Please treat it as such. Yes, that means you can't run the same source tree in two different Python versions -- too bad. It means adding a compilation-style step to one of the two Python versions -- too bad. It's quite easily automated, as proven by the vast majority of programming languages out there, which need such a step anyway.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Howver: If 2.6 doesn't support this it's not the end of the world.<br>
Because if it turn out to be necessary, a 2.7 that does could always<br>
be released. I don't know about other large codebases like Twisted,<br>
but the Zope/Plone world isn't likely to even try moving to 3.0 any<br>
time soon after it's final release, so since it's complicated you can<br>
probably wait with this support until it turns out to be needed.<br>
</blockquote><div><br>That was always the assumption, and also the idea for 2.6 and 2.7. I would much rather 3.0 isn't widely accepted for a few years longer than that it be cluttered with backward compatibility crap, and even rather than that widely used code be riddled with such. But it's up to Guido in the end.<br>
</div></div><br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org" target="_blank">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!