Re: Python policy update
On Sun, 2003-08-24 at 09:38, Joe Wreschnig wrote:
[...]
> pydance comes with a number of "modules", which are actually its core
> source code split into managable files. It installs these to
> /usr/share/games/pydance, and doesn't byte compile these. Based on my
> reading of this section, this is now not allowed anymore.
>
> However, I don't see a good reason for disallowing this. By not
> bytecompiling the modules, it means that the package works on any
> version of Python and Pygame meeting its minimum requirements, which is
> both 2.2 and 2.3. It is entirely platform-independent data, which means
> it can go into /usr/share, and be replicated across platforms more
> easily (although this doesn't matter much in the case of pydance
> specifically, I can see it mattering for other programs).
>
> Is there a reason that programs should bytecompile their modules? The
> startup time reduction, at least in pydance's case (6800 lines, 27
> files) is unmeasurable, it takes up more space, and means backporting
> the package becomes necessary for testing users.
The problem is, run pydance as any user with write permissions to
/usr/share/games/pydance, and the *.py's there will be compiled and
saved as *.pyc's using whatever version of python was used at the time.
When you de-install or purge pydance, the *.pyc's will be left behind.
When the default python changes version, the useless *.pyc's compiled
with the old version of python will stay there until pydance is again
run by someone with write access. While the old pyc's hang around, they
take up space and add slightly more overhead than no pyc's at all
(python will try them first before realising they were compiled with the
wrong version).
--
Donovan Baarda <abo@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/
Reply to: