[Python-Dev] Python language standard; LSB

Gustavo Niemeyer niemeyer@conectiva.com
Fri, 13 Jun 2003 20:43:59 -0300


> 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