On Wed, 31 Jan 2007 09:04:33 +0100, Roman Susi email@example.com wrote:
Josiah Carlson wrote:
"Jan Kanis" firstname.lastname@example.org wrote:
On Tue, 30 Jan 2007 23:31:36 +0100, Josiah Carlson email@example.com wrote:
Roman Susi firstname.lastname@example.org wrote:
def foo(x, y, z, bar=, qux=): if baz is Missing: baz =  #code
at least, it doesn't require decorators, is backward compatible (hopefully no grammar conflicts in there), reads as English.
The above with a missing value for a default *is not* backwards compatible with previous Pythons. New syntax is, by definition, not backwards compatible.
As a matter of fact, backward-compatible syntax changes are certainly possible. (ever wondered how C++ got it's syntax?) Any valid current python is still going to behave exactly the same if this syntax were to be accepted. Talking about backward compatibility, I think it is safe to ignore any text files that don't get accepted by the python interpreter. This syntax change would certainly not break any existing production python code. (note: the above statements do not entail in any way that I am in favour of this syntax change)
Fowards compatible then. That is to say, writing for the new proposed system will break compatibility with older Pythons. On the other hand, using currently-available language syntax and semantics is compatible among the entire range of Pythons available today.
"... a product is said to be backward compatible (or downward compatible) when it is able to take the place of an older product, by interoperating with other products that were designed for the older product."
"Forward compatibility (sometimes confused with extensibility) is the ability of a system to accept input intended for later versions of itself."
So, the right term is that Python 3000 will be in the syntactic aspect we discuss backward compatible because it will accept old syntax too.
Forward compatible?? There are exactly zero people on python-dev who care about that. What people care about is that a piece of python code written at the time of 2.4 will still run the same on python 2.5. That's backward compatibility. Nobody cares that a piece of python code using syntax constructs that were new in 2.5 won't run on python 2.4. If you want that, then don't use the new constructs. New syntax constructs get added to the language on just about every major revision, no python major version is forward compatible with a higher major version. Python 3.0 is specifically created to allow the backward incompatible changes that people deem nescessary, so neither forward nor backward compatibility matter in that respect. (well, except that it shouldn't become a superhuman task to convert 2.x code to run on python 3.0)