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

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



On Tue, Jan 06, 2004 at 01:44:17AM +0200, Lars Wirzenius wrote:
> 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.

Exactly, which is why I am so confused as to what all the fuss about pyc
and pyo files is all about.  They are optimizations, and the programs
work fine without them, and programs work fine with invalid ones, too.
The optimization gained gives Python a minimal edge over Perl in some
cases -- perhaps for CGI scripts -- but I have never yet seen a
situation in which pyc/pyo files made any kind of noticable performance
difference.

> 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

There are a lot of Python packages and Python modules in Debian that
have counter-productive dependencies.

Not only that, but Python policy tends to encourage such behavior
(section 3.2, for instance.)

Section 2.2.1 is totally, completely, utterly broken and stupid.  If I
ever run into situations where I need to make Python packages, I do it
the right way (python-foo depends on python2.3-foo, and also build
python2.2-foo) instead of the broken way.  But for pure python programs,
I just use python-foo and install them in /usr/lib/site-python.

Anything else is silly.

> (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.)

However, I'm not sure this has actually been accomplished.  I think it
would be better for Python in Debian to follow Perl's lead and have only
one version present at a time.  Python's backward compatibility actually
seems to be better than Perl, in general, and so this should not pose a
problem for us.

-- John



Reply to: