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

[Guido van Rossum]

> > Let me turn this around.  What advantage do you see to linking it
> > statically?
> 
> The trigger was that it would have simplified the build for me: When
> converting VC++6 projects to VC.NET, VC.NET forgets to convert the
> /export: linker options, which means that you had to add them all
> manually. Mark has fixed this problem differently, by removing the
> need for /export:.
> 
> Integrating _sre (and _socket, select, winreg, mmap, perhaps others)
> into python.dll still simplifies the build process: you don't have to
> right-click that many subprojects to build them.

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.

> In addition, it should decrease startup time: Python won't need to
> locate that many files anymore.
> 
> It also decreases the total size of the binary distribution slightly.

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'd say that making more extensions static on Windows would increase
start time of modules that don't use those extensions.

I'm -0 on doing this for _sre (I think it's a YAGNI); I'm -1 on doing
this for other extensions.

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