@teamquiggan: the name change? because i wanted to have a "cute" allegory in the name. and thanks

@NaYoN, ha1f, apodysophilia:
python & productivitycoding in python instead of C++ lets me implement stuff in one day that would otherwise take four (no joke!).
python in the wildpython is definately suitable for large applications: know battlefield 2014? the eninge is c/c++, everything else (game logic) is python.

btw: python isn't slow because of dynamic type checking (c++ needs to do that everytime you use inheritance), but because it's a scripting language. but with modern CPU speeds it "just doesn't matter" (tm). computers should make my life as developer easier, not the other way round... (of course it's even more important to create a good game)
using pygletpyglet over pygame wasn't really a choice. pygame is a pita (if not impossible, i have heard no success story yet) to set up under mac os x leopard, so i had to go with pyglet.
for what i'm doing now (just sprite blitting) it works perfectly. the event model is somewhat nicer than pygame and everything feels more python-ish instead of pygames "just make the sdl api available" approach.
pyglet & sprite rotationpyglet runs on top of opengl, while it offers no sprite rotation itself you can make the necessary opengl calls. as far as i see it is under heavy development, so if you write the developer a patch i'm sure he'd add it. it shouldn't be much more than
def blit_rotated(...):
glPushMatrix()
glTransformMatrixOrWhateverYouNeedToDo
blit() # call the usual blit method
glPopMatrix()
# profit!
besides that: i know that i'm going to need pixel-level editing of textures. i hope i don't run into any bigger obstacles while doing that.
let's see.
so far pyglet rocks!