Re: [pygame] Pygame's future beyond 1.8

["René Dudfield" <renesd@xxxxxxxxx>]

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 <pete@xxxxxxxxxxxx> 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.