"backward compatibility" defined (was Re: [Python-Dev] Identifying magic prefix on Python files?)

[Guido van Rossum]

> Thinking as a commercial software vendor: "Backward compatibility"
> means to me, that I can choose a stable version of Python (say 1.5.2,
> since this is what comes with the Linux Distros SuSE 6.2, 6.3, 6.4
> and 7.0 or RedHat 6.2, 7.0 is still in use on 98% of our customer
> machines), generate .pyc-Files with this and than future stable
> versions of Python will be able to import and run these files, if I
> payed proper attention to possible incompatibilities like for
> example '[].append((one, two))'.

Alas, for technical reasons, bytecode generated by different Python
versions is *not* binary compatible.

> Otherwise the vendor company has to fall back to one of the following 
> "solutions":
>    1. provide a bunch of different versions of bytecode-Archives for each
>       version of Python (a nightmare).
> or 2. has to distribute the Python sources of its application (which is 
>       impossible due to the companies policy)

Remember that Python is an Open Source language.  I assume that you
are talking about your company.  So I understand that this company
doesn't underwrite the Open Source principles.  That's fine, and I am
all for different business models.  But as your company is not paying
for Python, and apparently not willing to sharing its own source code,
I don't feel responsible to fix this inconvenience for them.

Now, if you were to contribute a backwards compatibility patch that
allowed e.g. importing bytecode generated by Python 1.5.2 into Python
2.1, I would gladly incorporate that!  My priorities are often
affected by what people are willing to contribute...

--Guido van Rossum (home page: http://www.python.org/~guido/)