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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4