Re: [pygame] Pygame's future beyond 1.8

[Phil Hassey <philhassey@xxxxxxxxx>]

> > 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 map" 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 slightly 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 everything.)
 3.  Distributions in general will probably only support one.
 4.  Major pygame libraries like pgu, ocempGUI, pygext, etc will either have the pain of trying to make sure that they are pygame and pygame-ctypes compatible, or they will have to choose 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 pygame, 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.  (And 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.