Re: [pygame] Pygame's future beyond 1.8

On 8/21/06, René Dudfield < renesd@xxxxxxxxx> wrote:

On 8/21/06, Luke Paireepinart < rabidpoobear@xxxxxxxxx> wrote:
>
> 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?
>

At this stage pygame ctypes does not address the problems I have.  The
pygame ctypes is already a fork of pygame.  So it's happened already.
At this stage I think we need to minimise any possible damage.

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

I don't think it is possible to have compatibility.  You will never be
able to write code for both and be sure without testing that your game
will work in a similar way.  I could most possibly be wrong about
this.

I will try, and definitely accept patches to help compatibility.
However keeping that compatibility might end up stiffling both
projects.

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

Note that the pygame C version is the more popular one at this stage.
Also pygame ctypes does not have all of the functionality of pygame or
the other way around.  There are definite advantages to using pygame
at the moment over pygame ctypes.

I don't really care that much about the popularity of something, but
that it works for people and that people don't waste their time.

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

Yes, at the moment that is my biggest problem.  However the other
issues are equally valid.

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

That's the plan of Pete, Alex, Richard and others.  However the
current pygame implementation will be continued by me(and anyone else
who feels like it).  At this stage I want to discuss how, and under
what name.