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

Re: [pygame] Growing Pygame



On, Mon Jul 24, 2006, Simon Wittber wrote:

[...]
> 1) Lots of pygame development is happening, lots of people want to
> share their work, but it is usually not immediately accessible and
> usually slips under most peoples radars. Pygame has not grown much in
> the last few years, even though people do see to want more. See this

Does it need to grow? "Lots of pygame development" is happening so how
and why should it grow? And in which ways should it?

Phil did a great job with the new pygame website, the instant addition
of projects and the wiki. In my opinion it really brings pygame forward,
because many more people now register their projects there to show, what
they have done. So it surely fits the most basic needs people have to have
to realize their ideas, not?

> Not a whole lot has happened since.

Hm, let me see. Clipboard support is on the way, a mature and stable API
exists and a more or less full backwards compatibility is maintained so
far. I would call that a lot, if you think about pygame as a wrapper of
SDL with several nice additions.

> 
> 2) It will help build better games faster. I'm reinventing the wheel
> all the time, (its a bad bad bad habit) however, I always use

Why do you reinvent the wheel all the time?

> officially blessed tools rather than my own. Having an officially
> blessed set of tools will help lots of people make easier decisions
> about what to use. A tool from the contrib module would become blessed
> when it moves into the pygame namespace.

Will it? Having an officially blessed set of tools does not mean, that
there no others, which might do the job better for that particular
case. It means: we recommend those, because they fit for our subjective
needs (without possibly looking to the left or right).
Once its in an official tree and you encounter a better tool with the
same approach, you only have the decision to stick with the blessed one
OR to break compatibility and import the new one. That can become
critical.

> A pygame contrib trunk could be created which is expected to work with
> the pygame svn head. When pygame is branched/tagged for release, so is
> pygame-contrib.
> 
> Barriers to entry for coders should be minimal. Eg. Plain ascii
> docstrings, tests using the unittest module and new style classes
> should be enough to get a piece of code considered for inclusion in
> pygame-contrib. The pygame-contrib maintainer(s) would vet submissions
> for correctness, consistency and usefulness. Once a piece of code
> proves its usefulness for general pygame development, it would be
> considered for inclusion into the pygame namespace by the pygame
> maintainer(s).

This would limit the contrib module to only small bits, not tools, but
helpers, like e.g. that A-star algorithm, someone made for pygame and
stuff. I wonder, if that does not lead to more problems than it will
solve..

> So, who is with me? :) If the pygame maintenance crew thinks this is a
> good idea, I have an implementation plan ready for discussion.
> Otherwise, I'll just keep reinventing my wheels :)

I am a bit concerned. Not because I do not like that idea, but because
of the problems, it adds.
Instead of adding a new contrib package I would recommend to directly
add sufficient and well designed code into pygame's HEAD tree, add one
or two people with plenty of time to keep the code up to date and stable
and that's it as someone already suggested. A different branch, which
possibly can get out of sync with the pygame development does not bring
any value or pygame forward.

Regards
Marcus

Attachment: pgpwBNboODZ7u.pgp
Description: PGP signature