René Dudfield wrote:

>  Compatibility, pygame ctypes and pygame will never have complete api
>  compatibility.  

They do not have complete compatibility at the moment, but it is 
something I am striving for.  There is nothing inherently impossible 
about the task, though it could take some time.  At the moment the 
compatibility is "good enough" to run every game I have thrown at it.

>  They will also never have the same speed
>  characteristics.  Meaning more testing, and having to use the lowest
>  common denominator.  eg. if something is 10x slower with pygame ctypes
>  then it can not be used.

I agree with Richard: that Pygame-ctypes should become Pygame 2.0 only 
if and when it becomes performance competitive.  It is nowhere near this 
stage at the moment.  But it is something I think will be possible, in 
time.  If anything is 10x slower with Pygame-ctypes I would object to it 
becoming the main trunk.

>  Working on other platforms, pygame ctypes works on windows, linux, and
>  macosx.  sparc, mips, alpha, arm, and other weird used platforms are
>  not supported.  For me, this means that pygame ctypes does not work on
>  some of my machines.  ARM being the major platform that I want to
>  support.

ARM support for ctypes is currently under development.  I suspect that 
as Python 2.5 gains popularity, so will ctypes and its platform 
support.  If there are major platforms still unsupported by 
Pygame-ctypes when and if the 2.0 push comes, we should delay it until 
they are (though I personally am not sure that SPARC, MIPS or Alpha 
qualify).

>  Speed, obviously C & asm are faster than python.

There are currently no hand-coded assembly paths in Pygame.  The major 
performance bottlenecks of Pygame-ctypes at the moment are in the draw, 
transform and image modules.  These will get alternate pathways written 
in C, Pyrex (which compiles to C) or something else. 

In the more general case, the small amount of Python wrapper that exists 
on every Pygame-ctypes function will indeed make it perform slower than 
its Pygame counterpart.  I would argue that if this small performance 
penalty is significant for a particular project, then that project is 
not really suited to be implemented in Python.

>  As you mentioned, some parts need C anyway.  Taking away one of the
>  main benefits of ctypes, and that is being able to contribute without
>  a C compiler.  

Indeed, they only need a C compiler if they wish to contribute to a part 
that is written in C (or Pyrex, etc.).  The real benefit here is not in 
removing the requirement for a C compiler, it's in speeding up the 
development process---avoiding the recompile-link-debug cycle for most 
development.

>  By requiring a C compiler it is easier to include other
>  C libraries.

Not at all.  Witness Pygame-ctypes's extensive use of SDL, SDL_image, 
SDL_mixer and SDL_ttf.  Any library can be written for using ctypes.

>  Pygame works already, meaning that I see no reason to use something else.

There have been other threads discussing the advantages of moving to a 
ctypes-based module; see for example the Pygame-ctypes home page.

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.

Regards,
Alex.