Alex Holkner wrote:
>  Regarding your comments [in "new pygameC or pygame."] about a name 
>  change, I agree completely with everything you say.  If the issues 
>  above cannot be resolved and there are two Pygame-like modules in 
>  active development, Pygame-ctypes should change its name, preferably 
>  to something that doesn't look at all like "pygame", and Pygame should 
>  continue in its current namespace.
>  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.
This sounds like it has the potential to be another 
numeric-numarray-numpy-scipy confusion-fest.
I would really like it if there weren't two similar libraries I had to 
choose from.
Renee, do you really foresee enough problems to justify forking?
If Alex's development goes as he claims, and he addresses most of the 
issues you raised,
would that be enough, or are you planning on forking no matter what?

Either way, maintaining two separate python SDL implementations and 
trying to keep compatibility between their APIs
will be hard.  Is there going to be an attempt at this?  Right now, at 
pygame 1.8 and pygame-ctypes 0.08 there
seems to be enough compatibility for them to be mostly interchangeable 
(AFAICT).  After the fork, does the compatibility disappear?
Does the fork in your mind (Renee) clear you of responsibility of 
maintaining this?

If the average joe is writing a library for pygame 2.0, is he going to 
have to make numerous
but subtle changes for his program to support the alternate fork?  If so,
what motivation does he have to do this?  If his target audience is 
using mostly pygame 2.0, he's good to go.
So if compatibility between the forks isn't maintained, module authors 
will have to learn how to write
for both APIs, or side with one. And if the majority side with pygame 
2.0, then I can't see that many people
would even want to use the alternative.
Whether or not people feel C Pygame or Pygame-Ctypes is better, it's 
which one gets the most support
that will succeed, similar to the Windows vs. Linux vs. Mac.  Most 
people have Windows installed
so most programs are authored with Windows support.  If most people have 
pygame-ctypes
most programs will be written for it, right?  In this case, is it really 
worth the added confusion
of having two modules that do basically the same thing, just so we can 
keep a current version of C pygame
for the few people who use it?

It seems to me the biggest issue (once pygame-ctypes is stable and 
optimized)
is that pygame-ctypes only supports platforms that ctypes supports, whereas
C pygame works on any platform with a C compiler.

Could we make C Pygame sort of a legacy version that's maintained for the
people whose architecture doesn't support ctypes yet, and encourage them 
to upgrade to
pygame 2.0 whenever they get ctypes support?  If C Pygame is kept 
current to pygame 2.0
it will be harder to get people to use 2.0.  Once Pygame 2.5 is out, as 
Alex said,
ctypes will be ported to more platforms, right?

-Luke