[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: python again (was: Bug#225999: ITP: debsync -- installed packages synchronization tool)



ti, 2004-01-06 kello 00:33, Andreas Barth kirjoitti:
> * Matt Palmer (mpalmer@hezmatt.org) [040105 22:10]:
> > On Mon, Jan 05, 2004 at 08:20:01PM +0100, Andreas Barth wrote:
> > > * Will Lowe (harpo@thebackrow.net) [040105 19:55]:
> > > > But since we allow the user to have several versions on Python on the
> > > > system at the same time
> 
> > > Why is this necessary at all? There is no possiblity to have different
> > > perl versions installed at the same time.
> 
> > Perl has some sense of backward compatibility?
> 
> If this questions should mean that Python has not, than Python is
> fundamentaly broken, and using Python anywhere important would mean an
> error. Thanks for clarification.

Indeed. I have a package in the Debian archive, enemies-of-carlotta,
which works fine with Python 2.1, 2.2, and 2.3. I have every expectation
that it will work fine with future versions of Python as well. I use the
same .deb on machines running woody and sid. Any problems I may have are
not due to Python.

It does compile it's .py files to Python byte code upon installation,
using whatever is the default version on the machine it is installed on.
If the default version later changes, and the new version (which might
be an older version of Python) has an incompatible byte code, nothing
will majorly break: the Python interpreter will ignore a byte code file
for the wrong version and compile things when the program starts up
instead. Program startup will be slightly slower, that is all.

I don't know why it is so problematic to backport Python packages from
sid to woody, since I haven't had such problems. Perhaps Debian's Python
policy needs adjustment to make it easier. I claim, however, that it is
not inherent in either the Python implementation or the Debian Python
policy that such backporting be difficult.

(Incidentally, a major reason to allow several versions of Python on the
same system is specifically to make it easier to test your programs on
several versions of the implementation to make backports *easier*, not
more difficult.)

-- 
http://liw.iki.fi/liw/log/



Reply to: