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