pf@artcom-gmbh.de (Peter Funk) writes:

Hi,

Tim Peters wrote:

...

This is contentious every time it comes up because of "backward compatibility". The contentious part is that no two people come into it with the same idea of what "backward compatible" means, exactly, and it usually drags on for days until people realize that. In the meantime, everyone thinks everyone else is an idiot <wink>.

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))'.

Really? This isn't the case today, is it? The demise of UNPACK_LIST/UNPACK_TUPLE springs to mind. Changes in IMPORT_* opcodes/code-generation probably bite too. I can certainly remember occasions in the past few months where I'be updated from CVS, rebuilt and forgotten to blow the .pyc files away and got core dumps as a result.

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).

Oh, hardly. I can see that making sure that people get the right versions might be a drag, but not a severe one. You could always distribute *all* the relavent bytecodes - they're not that big.

or 2. has to distribute the Python sources of its application (which is impossible due to the companies policy)

decompyle? This isn't going to protect you against anyone with a modicum of determination.

or 3. has to distribute an own version of Python (which is a similar nightmare due to incompatible shared library versions (Tcl/Tk 8.0.5, 8.1, ... 8.3) and the risk to break other Python and Tcl/Tk apps installed by the Linux Distro).

I don't believe this can be unsurmountable. Build a static executable.

So in the closed-source-world bytecode compatibility is a major issue.

Well, they seem to cope without it at the moment... Cheers, M. -- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5