>  I am with Richard in planning for Pygame-ctypes becoming the trunk and 
>  future development on Pygame stopping at 1.8.x.  Your expertise in 
>  Pygame would be invaluable in implementing the required optimisations in 
>  Pygame-ctypes, and I would not like to see the community forked.

Why do all people think, that forks are bad? In my opinion this fork
would bring greater benefits to the pygame community. Both versions
can be developed for their very own needs and tweaks. The C version is
definitely suitable for environments with limited resources and
performance (e.g. embedded, older systems, etc.) while the ctype
overhead is not.

 Okay - here's my gripe about a fork (and a large part of the reason for my summary "road ma
p" of using pygame until pygame-ctypes is really ready to be the new pygame).
 
 A fork will cause me pain.  Here's why:
 
 1.  The website.  Which project is it for.  Or is it for both.  But if both are even slight
ly different, then the cookbook and documentation areas become confusing.  If it is just for
 one, depending on my "feelings" I may have to build an additional website for the pygame of
 my choice.
 2.  Linux distribution of my games.  "Game X depends on pygame-X" "Well, my distro only has
 support for pygame-Y" ... No profit in that for me.  Less linux users will play my games if
 they don't work everywhere out of the box.  (Non issue for win32 distribution as I py2exe e
verything.)
 3.  Distributions in general will probably only support one.
 4.  Major pygame libraries like pgu, ocempGUI, pygext, etc will either have the pain of try
ing to make sure that they are pygame and pygame-ctypes compatible, or they will have to cho
ose one or the other.  
 
 Again, to reiterate my roadmap:
 
   1.  pygame continues as the lead in pygame, new features etc.
   2.  pygame-ctypes follows step-by-step pygame and makes sure to be 100% compatible on its
 python interface
   3.  pygame-ctypes is made to work on all platforms supported by pygame ATM
  4.  pygame-ctypes should NOT use any c code (no using c, pyrex, swig, etc.)
  5.  when pypy makes python fast, and it makes pygame-ctypes as fast (or faster) than pygam
e, we switch to using pypy and pygame-ctypes, and drop pygame and python.
 
 The SDL_gfx comments I made in my last note would help #1, #2, #4 be even more likely.  (An
d as a side benefit help out the SDL community that we all owe quite a bit to.)
 
 Phil

 			
---------------------------------
Do you Yahoo!?
 Everyone is raving about the  all-new Yahoo! Mail Beta.