[Python-Dev] this is what happens if you freeze all the modules required for startup

[Jurko Gospodnetić]

   Hi.

On 14.4.2014. 23:51, Brett Cannon wrote:
> Now the question is whether the maintenance cost of having to rebuild
> Python for a select number of stdlib modules is enough to warrant
> putting in the effort to make this work.

   I would really love to have better startup times in production, but I 
would also really hate to lose the ability to hack around in stdlib 
sources during development just to get better startup performance.

   In general, what I really like about using Python for software 
development is the ability to open any stdlib file and easily go poking 
around using stuff like 'import pdb;pdb.set_trace()' or simple print 
statements. Researching mysterious behaviour is generally much much 
MUCH! easier (read: takes less hours/days/weeks) if it ends up leading 
into a stdlib Python module than if it takes you down into the bowels of 
some C module (think zipimport.c *grin*). Not to mention the effect that 
being able to quickly resolve a mystery by hacking on some Python 
internals leaves you feeling very satisfied, while having to entrench 
yourself in those internals for a long time just to find out you've made 
something foolish on your end leaves you feeling exhausted at best.

   Not considering the zipped stdlib technique mentioned in other posts, 
would it perhaps be better to support two different CPython builds:
   - one with all the needed stdlib parts frozen - to be used in production
   - one with only the minimal needed number of stdlib parts frozen - to 
have as much of the stdlib sources readily accessible to application 
developers as possible

   The installer could then perhaps install both executables, or the 
frozen stdlib parts could perhaps be built as a separate DLL to be 
loaded at runtime instead of its content being used from their Python 
sources.

   OK... just my 2 cents worth... :-)

   Best regards,
     Jurko Gospodnetić