[Python-Dev] _sre as part of python.dll

[Guido van Rossum]

> > I never have to do that; the dependencies in the project file make
> > sure that the extensions are all built when you build the 'python'
> > project.
> 
> Are you sure? If the python target is up-to-date (i.e. nothing has to
> be done for python_d.exe), and I delete all generated _sre files
> (i.e. sre_d.pyd, and the object files), and then ask VC++ 6 to build
> the python target, nothing is done.
> 
> Indeed, I cannot find any place where it says that the python target
> is related to _sre. I can only see dependencies with pythoncore.
> 
> Can you (or any other regular pcbuild.dsp user) please guess what I'm
> doing wrong?

I have no idea.  It's all magic for me.  But I never delete targets
manually.

> > Maybe _sre is used by most apps (though I doubt even that).  But
> > _socket, select, winreg, mmap and the others are definitely not.  On
> > Unix, all extensions are built as shared libraries, except the ones
> > that are needed by setup.py to be able to build extensions; it looks
> > like only posix, errno, _sre and symtable are built statically.
> 
> I do believe that is a mistake, as it will increase startup time of
> applications that need them; applications that don't need them would
> not be hurt if they were in the python binary.

But is the startup time of apps that use a lot of stuff the most
important thing?  I'd say that the startup time of apps that *don't*
use a lot of stuff is more important.  I'm not sure that making the
binary bigger doesn't slow it down.

> > I'd say that making more extensions static on Windows would increase
> > start time of modules that don't use those extensions.
> 
> I guess I have to measure these things.

Yes, please.  We switched to building almost all extensions as shared
libs when we switched away from Modules/Setup to setup.py.

--Guido van Rossum (home page: http://www.python.org/~guido/)