On Sat, Feb 14, 2009 at 11:23 PM, Robert Kern <robert.kern@gmail.com> wrote:
I have a couple of issues with this feature as implemented in setuptools. I think they should be addressed if the feature makes its way into the stdlib:
1. The pkg_resources import can make startup time quite large. For small command-line utilities like my grin tool and DivMod's PyFlakes, this can make them unusable. If you bring the feature into the stdlib, please pay attention to the overhead of locating the real script however you end up doing it.
Right, it getting very slow when you have a lot of sitedirs and .pth files, I think an API in pkgutil should handle this part and focus on performances, There's a patch I have started for this, that takes back pkg_resources import principles to look for a packages to return their metadata. http://bugs.python.org/issue4908
2. In the generated script, please use "if __name__ == '__main__':" to block out the executable bits. Currently, multiprocessing does not work on Windows when the application is started by a console_script. Because Windows does not have a true fork, multiprocessing will start up clean Python subprocesses that import the __main__ of the parent process.
OK, I'll point this thread in the ticket Tarek