[Python-Dev] Re: "backward compatibility" defined

[Michael Hudson]

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