Zack Schilling <[email protected]>:
I don't think manually including bufferproxy when it might not be needed is a good solution, nor do I think getting py2exe to search for compiled C modules calling other compiled C modules is likely to happen.
Right. That's not what I wanted to propose and I guess the one or other idea did not want that, too. The problem is that py2exe fails as it can't resolve inter-module dependencies on the C level. The solution would be to fix that with some separate python methods within the module(s), so the namespaces won't be polluted. Or to provide an example py2exe script, which includes all necessary modules for the minimum case. The py2exe example will currently require around 75 percent of pygame anyways, due to pygame's internal structure. pygame's current main initialisation file tries to import 75 percent of all available modules on the other hand. Which leaves just some modules, which are purely available for internal purposes and which could be easily provided with some well-documented py2exe example script or an __init__.py that incorporates them.
I think some documentation or a quick exception when the package fails to load would be sufficient. Wouldn't it make more sense to change "import_pygame_bufferproxy()" in pygame.h to throw an exception with a helpful message?
That's usually done by the C API already. pygame's current __init__.py however hides nearly all import errors and sets up some lambda expressions that cause code to fail badly in case the module could not be imported correctly. To fix the import issue, the initialisation system has to be fixed first. Regards Marcus
