skip@pobox.com schrieb:
Taking one example from this thread, Python's bytecode has always been an internal implementation detail.
I think that has stopped being true at least since I wrote 1997, or perhaps even since dis.py was written (i.e. right from the beginning of the language). With dis.py, the bytecode instructions are documented, and their numeric values accessible through opcode.h. What *hasn't* been documented is the marshal format, as it may change across releases. That hasn't stopped people from using the format as if it were specified, e.g. there is a Perl reader for marshal data: http://search.cpan.org/~simonw/Python-Serialise-Marshal-0.02/lib/Python/Seri...
If I read the thread correctly there is at least a request (if not a requirement) to make it part of an external ABI if Python is to become part of the ABI. That may or may not be a large technical challenge, but I think it would be a significant philosophical change.
The philosophical change would be that a specific version of that would be standardized. The "current" version could still evolve in a less documented way.
Martin> In any case, having Python in the LSB means that ISVs (software Martin> vendors) who target LSB (rather than targetting specific Linux Martin> distributions) could develop their applications also in Python Martin> (whereas now they have to use C or C++).
Why? Lots of people write portable Python programs today.
But if they distribute them, they either have to request that a Python interpreter is installed on the target system, or they have to ship a Python interpreter with their installation DVD (as they can't rely on Python being available on the system, in a certain version). With LSB specifying that Python must be present, and must have a certain (minimal) version, they can include Python scripts in their application, and they will work out of the box without the administrator of the target machine having to do anything. Regards, Martin