Martin v. Löwis wrote: >> I don't think I fully understand the reason why additional .pyd >> modules were built into the .dll. OTOH, this does not help anyone, >> since: > > The reason is simple: a single DLL is easier to maintain. You only > need > to add the new files to the VC project, edit config.c, and be done. No > new project to create for N different configurations, no messing with > the MSI builder.
FWIW, this just highlights how ineffecient your build system is. Everything you currently do by hand could be automated, including MSI generation. Also, you describe the Windows procedure, which I suppose it does not take into account what needs to be done for other OS. But I'm sure that revamping the Python building system is not a piece of cake. I'll take the point though: it's easier to maintain for developers, and most Python users don't care. > In addition, having everything in a single DLL speeds up Python > startup a little, since less file searching is necessary. I highly doubt this can be noticed in an actual benchmark, but I could be wrong. I can produce numbers though, if this can help people decide. >> Can we at least undo this unfortunate move in time for 2.5? I would >> be grateful if *at least* the CJK codecs (which are like 1Mb big) >> are splitted out of python25.dll. IMHO, I would prefer having *more* >> granularity, rather than *less*. > > If somebody would formulate a policy (i.e. conditions under which > modules go into python2x.dll, vs. going into separate files), I'm > willing to implement it. This policy should best be formulated in > a PEP. > > The policy should be flexible wrt. to future changes. I.e. it should > *not* say "do everything as in Python 2.3", because this means I > would have to rip off the modules added after 2.3 entirely (i.e. > not ship them at all). Instead, the policy should give clear guidance > even for modules that are not yet developed. > > It should be a PEP, so that people can comment. For example, > I think I would be -1 on a policy "make python2x.dll as minimal > as possible, containing only modules that are absolutely > needed for startup". I'm willing to write up such a PEP, but it's hard to devise an universal policy. Basically, the only element we can play with is the size of the resulting binary for the module. Would you like a policy like "split out every module whose binary on Windows is > X kbytes?". My personal preference would go to something "make python2x.dll include only the modules which are really core, like sys and os". This would also provide guidance to future modules, as they would simply go in external modules (I don't think really core stuff is being added right now). At this point, my main goal is getting CJK out of the DLL, so everything that lets me achieve this goal is good for me. Thanks, -- Giovanni Bajo
-- http://mail.python.org/mailman/listinfo/python-list
