On, Mon Aug 21, 2006, Phil Hassey wrote:

>  > 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.
>  

>   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.)1

Well, now that's a _really_ critical problem. If the distribution does
not ship with the wanted package, it is a problem of the distribution
packagers, not yours, mine or of the possible pygame forks.

>   3.  Distributions in general will probably only support one.

Again a distribution problem, not one of ours. Many software and forks
are not supported out of the box by distributions, but some software
relies on them (which is naturally not shipped with the distribution,
too), so what?

>   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.  

Which is the problem of the respective developers, not pygame's. When
X.org was forked from XFree86, tons of binaries (especially commercial
ones) either needed to be dropped or rereleased with matching
compatibility layers, because several distros simply dropped the XFree86
support and switched to X.org. Rude of them, isn't it?

Talking as developer, I do not care about that. If the people want my
software, they have to rely on what I force them to use (this is the
default for _any_ software). So those who want to use the stuff, will a)
either make it compatible (if not done by the author) or b) go ahead
with its dependencies.

As author of OcempGUI I do not see the point why _I_ have to maintain
two versions of my software and/or provide compatibility. I decide, what
I want the user to use. He can either stick with that or let it be. It's
up to him.
This definitely sounds ignorant, but it is also ignorant, that I force
the user to use e.g. Python > 2.3 and noone complains about missing
compatibility to Python 2.2, 2.0, 1.5, ..., so where's the problem with
that? if it does not fit the user's needs, he won't use it.

>   
>   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 i
ts 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.

And give all those people who wrote e.g. C library extensions using the
old pygame a kick in the butt. This will not be compliant with 4 ;-).

Whoa, I am just getting into a "bash-anything" mood, so do not take
anything said too serious :-).

Regards
Marcus