Re: [Pysdl-devel] Further development...

[David C. <si...@te...>]

As far as my needs go, I consider pySDL largely feature-complete right
now. I have a couple of very minor requests as stated below, but I
would support version 0.0.8 or 0.0.9 becoming 1.0, and future releases
simply being bugfixes or changes required to keep up with new features
in the C SDL libraries.

As far as future expansion goes, I think it's important to divide the
issue up into two groups:

1) Refining and improving current features: This I support. I'd still
like to be able to manipulate video surfaces as simple 3-d arrays (as
in fb[x][y][color], although fb[y][x][color] would be ok too) and I'd
like a fb.get_type() function, that returns either HWSURFACE or
SWSURFACE (although mustlock() does pretty much the same thing).

2) New, non-SDL features: These are features that the C version of SDL
doesn't support, such as saving surfaces as files, or drawing
primitives, such as rectangles, lines and sprite objects. I would
prefer not to see these features in pySDL. Suppose we implement
fb.save_png(), and Sam or Mattias release a new version of SDL_image
with a png save function in it? Which do we choose?

I'm not saying that a sprite class or sound file saving wouldn't be
useful; my current project would benefit greatly from a
free_scrolling_tile_based_hex_map class :) I'd just like to see pySDL
remain a tightly-focused, elegant and _limited_ project,
incorportating new features as they become part of SDL and its
accompanying libraries. If we want new features (such as save_png()),
perhaps we should advocate them to Sam first, so they can be placed in
the C project, then wrapped in pySDL.

Thanks for listening.

-- 
David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html