The whatsnew/3.0.rst document claims

"It is not recommended to try to write source code that runs unchanged
under both Python 2.6 and 3.0; you’d have to use a very contorted coding
style, e.g. avoiding print statements, metaclasses, and much more. "

This is no longer true, since 2.6 now has much backwards compatibility,
including fopr print statements and unicode, so it's prefectly possible
and not at all contorted to support both any longer.

I'd recommend that the above statement is changed to "under both Python
2.5 and 3.0" or simply removed.

No thanks.  We need to STRONGLY discourage such efforts.  The official
recommended approach is to run 2.6 with a -3 option to identify code
that cannot be automatically converted and then after making the
appropriate updates to use the 2-to-3 converter.  Trying to bypass that
path is asking for unnecessary pain.

That is not true, and statement as it stands now is still factually
incorrect.

Guido, the OP wants you to change your long-standing guidance on the
relationship between 2.6 and 3.0.  Care to pronounce?

It is true for 2.6 unless you use various from __future__ imports, which
I consider a form of contortion.

Even with 2.6 I don't see how you can specify a metaclass without doing
something weird like

  foo = MyMetaclass('foo', bases_tuple, namespace_dict)

which is hardly an improvement over either the 2.x or 3.0 syntax.

Given that it will always be true for 2.5, I don't want to back down.

A future import is not much of a contortion, and metaclasses is not
exactly an everyday occurrence, after 9 years of python I have yet to
write a metaclass...

Of course I don't like that it specifically mentiones 2.6, while 2.6 has
lot's of forwards compatibility just to make it possible to write code
that runs under both. It will always be true for 2.5, and then we could
fix the issue by changing 2.6 to 2.5. 

If you want to keep the statement for 2.6, it could possibly be
reformulated less strongly, or as a minimum change come up with another
example than something that actually has a forward compatibility in 2.6.

You're misrepresenting or misunderstanding the goal of 2.6.  Its goal
isn't to make it easy to write code that runs under both.  Its stated
goal is to make it easy to write code that can easily be *ported* to
3.0.  That's a very different story.

I will not be taking it back.

If you want further discussion on this, open a thread on python-dev.

I've never said that is the goal. You are misrepresenting or
misinterpreting my standpoint.

Then what did you mean by "just to make it possible to write code
that runs under both" ?

Well, that *is* the intention of a from __future__ import, isn't it?
That doesn't mean that's the intention of 2.6 as a whole, just that
statement.

But that's all part of the "make it easy to port" strategy.

I stick to my claim that trying to write code that runs unchanged in 3.0
is a non-goal of Python 2.6, and I do not want to suggest that this is a
good idea in the official documentation.

Fair enough, but I still think we can come up with a better example that
requires more contortions than "print", which doesn't. 

I think a good example of contortions is binary file data, which has two
different types in 2.6 and 3.0. Also making sure that you use iterators
all the time when using large sets of data can get quite contorted.