Le vendredi 30 décembre 2005 à 12:33 -0600, Joe Wreschnig a écrit : > 1. Stop compiling .pyo files, entirely (I'm hoping for little argument > on this). > > Rationale: .pyo files are a joke. They aren't optimized in any > meaningful sense, they just have asserts removed. Examples for several > non-trivial files: If there isn't any real optimisation inside, this is indeed meaningful. > 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? > * 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. > * .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. > * If we don't care about byte-compilation, the multi-version > support suggested in 2.2.3 section 2 becomes much easier -- > just add that directory to sys.path (or use the existing > unversioned /usr/lib/site-python). .pyc files are the rationale > between tight dependencies on Python versions, which is the last > of my suggested changes. Yes, this is indeed the root of all the dependency nightmare. > How?: dh_python should not call compileall.py unless give some special > flag. Python policy 2.5 should change "should be generated" to "may be > generated." On the other hand, the removal code should be a "must" to > avoid littering the filesystem if .pyc files do get accidentally > generated. > > I'm willing to write the patch for dh_python if there's agreement on > this. I can take care of dh_python. Maybe we could agree on what should be done before rushing into patches. > The Python standard library should still compile .pyc files, because > this is a prerequisite for any program to make good use of .pyc files. > The problems don't apply here, because it's easy to keep the interpreter > and standard library in sync. To extend this: the problems don't apply to any package that includes binary modules - which are tightened to a specific python version. > 3. Python dependencies should be loosened (and here I expect a > flamewar). > > Rational: Python migrations in Debian suck, period. One reason for this > is that every Python program and module has a strict dependency on > python >> 2.x, << 2.x+1, so during a Python migration absolutely > everything must be rebuilt. But most pure-Python programs and modules > are upward-compatible, especially these days when Debian is a minor > version behind. > Without .pyc files, there's no reason for this tight dependency at all. > Even if we keep .pyc files, I think loosening this requirement is a good > idea. Programs will still run perfectly fine with mis-versioned .pyc > files; the worst we'll see is some slightly longer startup times. 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. Regards, -- .''`. Josselin Mouette /\./\ : :' : josselin.mouette@ens-lyon.org `. `' joss@debian.org `- Debian GNU/Linux -- The power of freedom
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=