Compatibility, working on other platforms, speed, some parts need C
anyway, pygame works already.
Compatibility, pygame ctypes and pygame will never have complete api
compatibility. 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.
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.
Speed, obviously C & asm are faster than 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. By requiring a C compiler it is easier to include other
C libraries. All platforms have at least one C compiler available for
free. The main platforms have a choice of C compilers available.
Pygame works already, meaning that I see no reason to use something else.
These are the same reasons I shared before the beginning of the pygame
ctypes project. For some people pygame ctypes is a fine, and a
preferable option. I see no reason why the two can't exist together.
If the plan is to remove the current pygame, I do not want that to
happen. I also want the two to exist with as little confusion as
possible.
On 8/21/06, Richard Jones <[EMAIL PROTECTED]> wrote:
On Monday 21 August 2006 07:56, René Dudfield wrote:
> I do not plan to use pygame ctypes, and will continue C pygame.
Could you please share some of your reasons for doing this?
Richard
