Hey,
 
 To sum up my opinion - If I were the king of pygame and python world, this is how it would 
happen:
  
  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.
  
 Might be wishful thinking on my part in terms of pypy, but here's to hoping!  At present py
py is 1/4 the speed of python.  
 
 ..
 
 (for a longer edition of my thoughts with some more details see my commentary...)
 
 - 2/12 of my games work with pygame-ctypes.  Most of those bugs, I suspect are easily fixab
le, sans the c-land issues.  So I'd be guessing by the end of this week, 10/12 games will wo
rk.
 
 - set_at, get_at, and some stuff is very very slow.  That, I guess, is expected, however fo
r me speed is a *huge* issue with games.  I spend much of my time eeking out all the perform
ance I can get with pygame, and lately have taken to using swig and c to get just a bit more
!
 
 - I don't like the idea of there being two commonly used pygame distros out there.  Imagine
 pyweek, for example, which edition of pygame would be the definitive one for the compo?  (E
specially for those of us who are going to be using some custom c code in our entries, most 
likely.)
 
 - I think it would be okay for pygame-ctypes to become _the_ pygame once
 ** It is as fast as pygame.  Not "almost as fast".  Games are graphically intense items, an
d frames per second is a real issue.  Speed becomes an even greater issue when using python,
 since that gives me a huge penalty over C to begin with as far as graphics go.  I can't spa
re any more speed penalty for using pygame. **
 and
 ** it works on all the platforms, including the obscure ones **
 
 - pygame-ctypes should *not* use any C code.  That would really defeat the point.  If we're
 going to use c code for pygame-ctypes, we might as well just use pygame.  No using pyrex ei
ther.  That would be even worse, as it's a python generator of C code.  (And despite my soft
 spot for it, the same goes for swig.)  I would allow for using something like cinpy (tinycc
 stuff, does the compiling in memory), but not everyone in the world uses x86, so that's not
 acceptable either.  I say pygame-ctypes needs to be 100% python to be at all useful.
 
 - I can accept the c-land break for my on some of my games as long as there is a cut-off be
tween using pygame and pygame-ctypes.  At that point I can adjust my games to work with the 
new c-API.

 Phil
 
Alex Holkner <aholkner@[...].au>  wrote: flyaflya wrote:

>  Don't remove the C pygame,I think spliting C pygame and  ctypes-pygame 
>  to two separate projects is a good idea,So we will have more 
>  chioce,and ctypes-pygame can have special features itself and needn't 
>  to be compatible with  C pygame.
>  Maybe a reason I choice C pygame is because py2exe can't bundle the 
>  dll files ctypes need to the exe file.

Pygame-ctypes works fine with py2exe.  I used the setup.py:

---

from distutils.core import setup
import py2exe

setup(windows=['sample.py'],
      options={
        'py2exe': {
            'excludes': ['Numeric', 'numarray', 'numpy']
        }
      })
---

The default icon and font are missing, but that is a fixable problem.

Alex.


 		
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1�
/min.