Hi Peter. What do you think about sharing the pygame website with the pygame ctypes parts?
I would like to keep the project websites completely separate for the moment. I think this for the same reasons that Phil listed. If you want to have them on the same website I would rather start a new website for the current pygame under a new name. Do you still plan to use the 'pygame' module name for the pygame compatibility layer? Using the pygame module name will cause too much confusion, testing, and distribution problems. Something like this may be an option: import nameofcompatibilitymodule as pygame from nameofcompatibilitymodule.locals import * That way people can use both the current pygame and pygame ctypes at the same time if they need too. Also people have to explicitly say they are using the pygame ctypes one, which will mean they know which module they are using. If you want to use the pygame module name, I would rather put the current pygame under a new module name than continue with both sharing the same name. Changing the names will cause possibly even more problems. However I think that would be best for people wanting to use the current pygame if you want to continue development of pygame ctypes under the name of pygame. Cheers, On 8/23/06, Peter Shinners <[EMAIL PROTECTED]> wrote:
(The thread has blossomed. I think I'm all caught up on reading.) The Pygame on ctypes project has gotten me more excited about Pygame than anything. Alex has done an amazing job not only at getting this put together, but exploring various avenues of development that did and didn't work out. The crown jewel in the ctypes pygame code is the sdl layer. I'd like to get this released soon, without the pygame stuff. It sounds like this would be best handled as a completely separate project. Coding for straight SDL in Python is still an ugly prospect, but this is the level where I'd like to do some experimenting and development. The "pygame compatibility layer" would be something separate from these as well. Probably distributed as an egg in some form that won't automatically get confused with "Pygame proper". I think the results of ctypes-pygame will be a more agile and lightweight library. It will easily mix with a variety of other libraries for things like rendering and transforms. It will be easier and faster to develop with, and more effective at trying new things. There are a few hurdles left for ctypes. Primarily platform stuff like ARM and Win64.
