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

[Jan Kanis]

On Wed, 31 Jan 2007 09:04:33 +0100, Roman Susi <rnd at onego.ru> wrote:

> Josiah Carlson wrote:
>> "Jan Kanis" <jan.kanis at phil.uu.nl> wrote:
>>
>>> On Tue, 30 Jan 2007 23:31:36 +0100, Josiah Carlson <jcarlson at uci.edu>
>>> wrote:
>>>
>>>> Roman Susi <rnd at onego.ru> 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.
>>>>
>>>> - Josiah
>>>
>>> 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.
>
>> From wikipedia:
>
>
> "... 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.
>
>
> Regards,
> Roman
>
>

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)

- Jan