[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] Pygame's future beyond 1.8
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?
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?
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?
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.
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