"Jan Kanis"
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.
There are many developers who concern themselves with writing code that will work on version x and x+1 of Python. There are also people who like to use "bleeding edge" features while also using an older Python. If there weren't, then 'from __future__ import generators' wouldn't have existed in Python 2.2, 'from __future__ import floor_division' wouldn't exist in Python 2.3+, 'from __future__ import nested_scopes' wouldn't have existed in Python 2.1 or 2.2 (I can't remember), etc. Yes, there is new syntax with each later Python that won't work with previous Pythons, but with the vast majority of syntax changes that have come down (including the with statement in 2.5), the semantics of the new syntax are defined by using the previously existing language. In this case, the 'def foo(x=):' has a translation into current Python, but it turns out that the translation is *exactly what you should be doing today* if you care about correctness.
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)
The reason I concerned myself with this in regards to the 'def foo(x=)' proposal is because the ultimate point of this is to make writing code *less* buggy. However, code can be *less* buggy today through the proper application of an if statement or conditional expression. Yes, Py3k does allow for incompatible syntax. But the syntax changes aren't going to be "becase we can", they are going to be "because this way is better". Leaving out an argument isn't better (in the case of the 'def foo(x=):' syntax); it's ambiguous at best, confusing and worthless at worst. We can argue all day about writing compatible code, breaking compatibility, etc., but the fact remains: no developer who has any pull in python-3000 or python-dev has come out in favor of changing default argument semantics in this thread. - Josiah