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))'.
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)
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).
or 4. has to port the stuff to another language platform (say Java?) not
suffering from such binary incompatibility problems. (do u believe this?)
So in the closed-source-world bytecode compatibility is a major issue.
Regards, Peter
--
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)
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