Tobias writes:

one thing that prevents the linux standard base to include Python (or Perl for that matter) is that there is no formal language standard with test cases. (For the LSB a subset might be enough.) http://www.linuxbase.org/futures/faq.html#scope

Exists there anywhere a rudimentary standard or are there plans to create one?

well, stop paying attention for a bit (well, for months to be honest) and see what happens. As Tobias knows, working on the LSB is my "day job", although he probably doesn't know I hang out here, too. The LSB standardization process has a number of steps in it; one of the key ones is demand. We're not really blocked on a language standard or test suite, as has been pointed out elsewhere, just picking a version and its' matching test suite is close to good enough. But what we don't have is any really burning need to add more dynamic languages to the LSB specification (a "posix shell" is included for installation script purposes, so there is one). What does it mean to be part of this standard? It means an application developer can count on specific functionality to be present on a conforming system. There are already two answers for that: you can bundle Python with your project, Zope-style, or you can build your package to require an lsb-conforming Python of a specific version to be installed as a condition of installation (e.g., rpm dependency). The LSB project already builds such a version of Python as part of the "LSB application battery". The LSB application battery is used as a testbed of various functionality, and part of that process is installing lsb-python and running the Python regression test suite (in fact, it was chosen - by me - for the existence of that test suite which managed to beat on some things we don't have any more formal tests for). Perl is not part of this at the moment, by the way. Plus, of course, most systems that are targets of this already include Python, and a bit of care in coding ought to make it possible to use the native version. So until someone builds a "business case" that there's a problem that can only be solved by trying to create a "standard" for Python within the LSB, I don't see a lot of reason for the LSB committee to worry about it... Cheers, Mats Wichmann