On Sun, 2006-01-01 at 19:09 +0100, Josselin Mouette wrote: > > 2. Stop compiling .pyc files (this I expect to be contentious), unless a > > package wants to. > > > > Rationale: .pyc files have a minimal gain, and numerous failings. > > > > Advantages of .pyc files: > > * .pyc files make Python imports go marginally faster. However, > > for nontrivial Python programs, the import time is dwarfed > > by other startup code. Some quick benchmarks show about 20% gains > > for importing a .pyc over a .py. But even then, the wall-clock time > > is on the order of 0.5 seconds. Lars Wirzenius mentioned that > > this time matters for enemies-of-carlotta, and it probably also > > matters for some CGI scripts. > > Do you have more complete figures about this time? Getting figures for this is difficult, because it varies a lot based on the length/complexity of the code, and the differences are just long enough that they matter for some things but not others. I'll try to put together a proper benchmark over the next few days. But IMO this is backwards; it should be the responsibility of those who want to optimize to show that it matters. > > * Generating them at compile-time means they won't accidentally > > get generated some other time. > > > * .pyc files are not really architecture independent. > > Which is why pure python modules are still in /usr/lib. Well, no, pure Python modules are in /usr/lib and /usr/share. Python policy says they should go in /usr/lib, but that's irrelevant given how many packages ignore it (dput, gajim, pydance, gdesklets, hal-device-manager, ipodder, linda, pygtk, quodlibet, reportbug, rss2email on my system). > > * .pyc files result in strange bugs if they are not cleaned up > > properly, since Python will import them regardless of whether > > or not an equivalent .py is present. > > Which makes things worse if they aren't cleaned correctly. > > The real fix for this issue isn't to stop generating the .pyc files. It > is to make python not generate any .pyc files at all when running as > root. Well, I would say, not generate any pyc files unless requested, regardless of whether or not the user is root. My goal was to propose this with minimal changes to the Python code, but I'm also open to doing this, of course. > > 3. Python dependencies should be loosened (and here I expect a > > flamewar). > > ... > > We could indeed remove the requirement from the python policy, but I > don't like the idea of implementing any solution that makes > outdated .pyc files lie around on the system. > > I can see two ways to go from now for dh_python. > > 1. Make, as you suggested, dh_python stop building .pyc files - but only > for python-only packages, by default. The former behaviour could be > enabled by a flag for modules that are affected enough by the > performance hit. For this solution to work, it would be better to make > python stop creating .pyc files when run as root. > > 2. Make a separate python-support (inspired from emacsen-support) > package that takes care of the byte-compilation. This is the solution > I've been working on the last weeks, but it isn't ready yet. In my opinion, 1 is the better course. As you said, 2 is a lot of work. Since I'm not convinced bytecode is desirable in the general case, I don't think it's worth maintaining such a python-support rather than just not using bytecode. I would be interested in seeing what you have so far. -- Joe Wreschnig <piman@debian.org>
Attachment:
signature.asc
Description: This is a digitally signed message part