<div class="gmail_quote">On Sat, Jun 26, 2010 at 8:59 AM, Stefan Reich <span dir="ltr"><<a href="mailto:wertiges.produkt@googlemail.com">wertiges.produkt@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

My complaint is about changing the syntax of "print".<br></blockquote><div><br></div><div>Okay.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

To reiterate, I am strongly in disfavor of Python 3 and will stick to Python 2, for as least as long as Python 3 breaks my scripts.<br></blockquote><div><br></div><div>This will be forever, because Python 3 will never become "more" compatible with Python 2. The split was intentional. As Python 2.7 is in RC phase, and is slated to be the final version of Python 2.x, that will be the last iteration of Python 2 to be able to be 'more' compatible with Python 3.</div>

<div><br></div><div>To address your points: Yes, Python 3 is a one-time backwards incompatible break with the language to fix some design decisions that were made early on that were determined to be a mistake. The transition to Python 3 is not immediate. It'll take some people (myself included) perhaps years to get around to it. But lots of tools were provided to ease the transition.</div>

<div><br></div><div>You can make your Python 2.x code compatible so it will run on Python 3 and Python 2. You can do it one script at a time, as you tweak one for other reasons, you can fix it up. The print issue, you can resolve by simply adding:</div>

<div><br></div><div>from __future__ import print_function</div><div><br></div><div>To the top of the file in Python 2.6. Thereafter in that file-- but only that file, so you don't have to migrate an entire library / ecosystem of code-- will use the print() function as exists in Python 3.</div>

<div><br></div><div>If your biggest complaint is the print statement/function -- man, you're looking small, and are in for a world of hurt when you get to the bytes/[string|unicode] split hits. But even that you can prepare for pretty readily, on a file by file basis. Start looking at which Python 2 strings are 'character text', and which are 'raw bytes', and mark them with b'' literals and such.</div>

<div><br></div><div>The -3 warnings Python 2.6 offers help a lot too.</div><div><br></div><div>It really doesn't take all that effort to make code which runs under both Python 2.6+ and Python 3, with rare exception (though sometimes there's a couple hoops), and that's not even talking about 2to3 automatically translating Python 2 code to Python 3 code.</div>

<div><br></div><div>But if you don't want to even put in the effort of idle, over-time, file-by-file-as-you're-there-might-as-well-tweak-my-prints compatibility transitioning, so be it. You're free to use Python 2 forever, but you'll be stuck on Python 2 forever.</div>

<div><br></div><div>There's no "as long as" -- its done. Python 2 is over with 2.7. The incompatibilities with Python 3 are intentional, and although slow, momentum for migration to Python 3 does in my anecdotal experience seem to be continuing steady -- so eventually, Python 3'll be the norm.</div>

<div><br></div><div>Not that Python 2.7 will then die completely, I'm sure. The pydev's have even stated it'll have a longer then usual bugfix maintenance period, recognizing some people will be on the Python 2 platform for years still.</div>

<div><br></div><div>--Stephen</div><div><br></div><div>P.S. Am I the only one who has never, ever, even *seen* a 'print' statement in non-toy or non-bash-script-style code in any application or even third-party library I looked at? Except, on occasion, for quick and dirty debugging. Perhaps because I'm more used to cross-platform to windows development, where a stray print can actually break the entire application (depending on contexts, if one is run under a service or sometimes even pythonw)</div>

</div>