[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Pygame's future beyond 1.8

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.