[Python-Dev] Re: Python language standard; LSB

[Mats Wichmann]

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