On Fri, 2005-12-30 at 22:59 -0600, Kenneth Pronovici wrote: > > About a month ago Steve Langasek and I discussed the state of Python > > packages on IRC, in particular the effects of bytecode compilation; the > > effectiveness (or lack thereof) of it, and how it tightens Python > > dependencies. I'd like to propose three changes to how Python modules > > are handled. > > I have a couple of questions. > > Do you intend this proposal to apply to Python libraries, or Python > applications, or both?
Both. As they're at the leaves of the dependency tree, applications would benefit most from having looser dependencies. Applications are also more likely to be pure-Python, rather than having some compiled parts. Finally, applications are the points where the packager will have the best idea whether bytecompilation matters or not. > I'm thinking that many applications (especially ones like EoC) would be > built for just a single version of Python anyway. In this case, why > would it matter whether we have pre-compiled bytecode around? Well, the goal is to not "build" them at all, just have the Python source lying around. Then when the default version changes, they don't have to change in any way. > What would you suggest doing about "hybrid" packages which are primarily > applications, but also want to make their modules available to other > Python programs? Same thing. Don't bytecompile the modules. Bytecompiling is useless. pychecker is a good example, because it's a pretty straightforward example of pure-Python modules whose run time dwarfs their compile time. pychecker's packaging is also a good example of how the current policy is totally broken. Without bytecompilation the current setup is totally sane, albeit policy-violating. With bytecompilation, it's both insane (since you're storing useless bytecode) and policy-violating. > Finally, what do you suggest doing with packages that contain both > pure-Python modules and C extensions? It seems that any package which > contains a C extension is necessarily tied to a specific version of > Python, and so might as well have pre-compiled modules. You didn't seem > to address this in your proposal, but maybe that's because you're > assuming that current policy is appropriate. Well, "appropriate" might not be the right idea -- "the best I can think of for now" would be better. As long as Python changes its library/soname each version, there's not much we can do about this. -- Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
