[Python-ideas] proto-PEP: Fixing Non-constant Default Arguments

[Josiah Carlson]

"Jan Kanis" <jan.kanis at phil.uu.nl> wrote:
> 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