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

Re: Python policy update

On Sat, 2003-08-23 at 23:54, Donovan Baarda wrote:
> 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.

The only such user should be root, who shouldn't be running pydance

> 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

Space that would be used anyway if I bytecompiled them; this argument
boils down to "you can use the space, or you can not use the space until
the sysadmin does something stupid". The second option is definitely a
better choice.

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

This doesn't take very long, I just tried it. Specifically, I couldn't
reproduce statistically significant differences between no pycs and bad
versioned pycs. Python probably embeds the version of the pyc in the
file so the check is fast.

And if one doesn't abuse one's administrator powers, this case never

OTOH, the benefits of not bytecompiling:
 - Unless the admin is stupid, space is saved.
 - The data is sharable across architectures.
 - Build-Depends are likely lessened.
 - The package migrates more easily between Python versions (and thus
more easily into testing, and eventually, is more easy to pin from

IMO this is worth a negligable startup overhead.
Joe Wreschnig <piman@debian.org>

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: