Python language standard; LSB
Hello, 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? Tobias
Tobias> one thing that prevents the linux standard base to include Tobias> Python (or Perl for that matter) is that there is no formal Tobias> language standard with test cases. (For the LSB a subset might Tobias> be enough.) http://www.linuxbase.org/futures/faq.html#scope Tobias> Exists there anywhere a rudimentary standard or are there plans Tobias> to create one? None that I'm aware of. Why is this important? Many Linux vendors already ship Python and Perl with their distributions. In fact, several of them rely heavily on one language or the other to develop their value-added system administration tools. Skip
None that I'm aware of. Why is this important? Many Linux vendors already ship Python and Perl with their distributions. In fact, several of them rely heavily on one language or the other to develop their value-added system administration tools.
... and infrastructure, installers, etc. -- Gustavo Niemeyer http://niemeyer.net
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?
Not really, and not that I'm aware of. In practice, there's only one Python implementation that could be used here (Jython doesn't make sense in this context) so I'm not sure what a standardization effort would buy us. It's not like there are lots of diverging Python distributions, like with Unix or the Linux kernel. Standardizing on a version might make sense; I would recommend using the 2.2 line of releases, starting with 2.2.3 (the latest 2.2 release), until 2.3 is considered stable. There is of course a thorough standard test suite for Python (contained in the test package in the standard library); Jython also strives to pass this test suite (except for some parts of the test suite that are platform specific). Other than that, I expect that including Python in LSB is more a matter of political will in the LSB committee than anything else. --Guido van Rossum (home page: http://www.python.org/~guido/)
Hi, On Fri, 13 Jun 2003, Guido van Rossum wrote: [Python Language Standard]
Not really, and not that I'm aware of. In practice, there's only one Python implementation that could be used here (Jython doesn't make sense in this context) so I'm not sure what a standardization effort would buy us. Hmm, at least with PERL there are concerns that the different PERL version have subtle differences. From the #lsb channel: <chris> The problem we have here is the standardisation of perl <chris> if we require perl on lsb systems, what does this really mean? Lots of versions out there with subtle incompatabilities
It's not like there are lots of diverging Python distributions, like with Unix or the Linux kernel. Well, even with things like the glibc, which exists only once and is in principle the same, you might hit problems (e.g. with different forms of threads) depending on the version.
Standardizing on a version might make sense; I would recommend using the 2.2 line of releases, starting with 2.2.3 (the latest 2.2 release), until 2.3 is considered stable. That was what chris ment (for Perl): While let's say Perl 5.6 and 5.8 are similar, they are not identical for certain applications (especially tainting and unicode). That is: One would like to know (e.g.) a subset which is _guaranteed_ to work.
While Python is more stable than perl in this respect (at least I have that expression) the problem is that there is no fixed python language: With any new release not only bugs are fixed, but also new language features are added. While this makes features-to-market faster, it probably creates the problems that make it hard to "standardize" python. This done when it is included in the LSB (kind of): The programs have to behave _identical_ independend of the python version.
There is of course a thorough standard test suite for Python Hmm. It should be somehow possible to get python (and perl) into the LSB, hmm.
Other than that, I expect that including Python in LSB is more a matter of political will in the LSB committee than anything else. I'm not that sure, at least for LSB 2.0 which is supposed to be modulized this might actually happen. (Though probably only if also Perl gets included.)
Tobias
On Fri, 13 Jun 2003, Guido van Rossum wrote: [Python Language Standard]
Not really, and not that I'm aware of. In practice, there's only one Python implementation that could be used here (Jython doesn't make sense in this context) so I'm not sure what a standardization effort would buy us. Hmm, at least with PERL there are concerns that the different PERL version have subtle differences. From the #lsb channel: <chris> The problem we have here is the standardisation of perl <chris> if we require perl on lsb systems, what does this really mean? Lots of versions out there with subtle incompatabilities
It's not like there are lots of diverging Python distributions, like with Unix or the Linux kernel. Well, even with things like the glibc, which exists only once and is in principle the same, you might hit problems (e.g. with different forms of threads) depending on the version.
Standardizing on a version might make sense; I would recommend using the 2.2 line of releases, starting with 2.2.3 (the latest 2.2 release), until 2.3 is considered stable. That was what chris ment (for Perl): While let's say Perl 5.6 and 5.8 are similar, they are not identical for certain applications (especially tainting and unicode). That is: One would like to know (e.g.) a subset which is _guaranteed_ to work.
While Python is more stable than perl in this respect (at least I have that expression) the problem is that there is no fixed python language: With any new release not only bugs are fixed, but also new language features are added. While this makes features-to-market faster, it probably creates the problems that make it hard to "standardize" python. This done when it is included in the LSB (kind of): The programs have to behave _identical_ independend of the python version.
This reveals a hopelessly naive view on standardization.
There is of course a thorough standard test suite for Python Hmm. It should be somehow possible to get python (and perl) into the LSB, hmm.
Other than that, I expect that including Python in LSB is more a matter of political will in the LSB committee than anything else. I'm not that sure, at least for LSB 2.0 which is supposed to be modulized this might actually happen. (Though probably only if also Perl gets included.)
Why would Python only be included if Perl was also included? As I said, this is just politics. --Guido van Rossum (home page: http://www.python.org/~guido/)
That was what chris ment (for Perl): While let's say Perl 5.6 and 5.8 are similar, they are not identical for certain applications (especially tainting and unicode). That is: One would like to know (e.g.) a subset which is _guaranteed_ to work. [...]
I think it's just a matter of including some specific Python version, and using the documentation for that version. If you get Python 2.2.3, any code designed for Python 2.2.3 will work on this Python version. OTOH, you can't freeze Python development to make it compatible with something forever. Not even programs like gcc work this way. As I understand it, the LSB has come to solve compatibility problems between different distributions of Linux. IMO, including Python in the LSB won't buy us anything (besides some marketing ;-). As an example, some time ago we could notice many users with problems about RedHat including an obsolete Python. OTOH, this wasn't a Python fault. There was a "standard" Python version which most distributions were following, and RedHat was not following the "standard". This might happen with or without LSB. Indeed, it has even more chance of happening if a *subset* of Python is "included" in the LSB. I must confess that nowadays I see the LSB mostly as a marketing tool, being used as an argument against those that are afraid of being attacked by the "Unix Syndrome" while adopting Linux.
While Python is more stable than perl in this respect (at least I have that expression) the problem is that there is no fixed python language: With any new release not only bugs are fixed, but also new language features are added. While this makes features-to-market faster,
Please, have a look at the mailing list archive. You'll find *long* discussions about this topic. :-)
it probably creates the problems that make it hard to "standardize" python. This done when it is included in the LSB (kind of): The programs have to behave _identical_ independend of the python version.
I don't think standardization makes sense while we have a single mainstream interpreter. -- Gustavo Niemeyer http://niemeyer.net
participants (4)
-
Guido van Rossum -
Gustavo Niemeyer -
Skip Montanaro -
Tobias Burnus