[Python-Dev] Python language standard; LSB
Guido van Rossum
guido@python.org
Fri, 13 Jun 2003 14:36:05 -0400
> 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/)