Monday, January 19, 2009

pygame, pywebsite -- a website with joystick controls???!??!

Here's a song program written with a pygame style api:

import pygame
pygame.init()

counts = {}
going = True

while going:

events = pygame.event.get()

for e in events:
if e.type == HTTP:

if e.path.startswith('/song/'):
song_id = e.path[6:]

if e.method == "POST":
counts[song_id] = counts.get(song_id, 0) + 1

e.write(counts[song_id])

elif e.path == "/":
if e.method == "GET":
data = ','.join(['%s=%s' % (k, v) for k, v in counts.iteritems()])
e.write(data)

elif e.method == "DELETE":
counts.clear()


elif e.type in [QUIT, KEYDOWN, JOYBUTTON, MOUSEDOWN]:
going = False


Note this is not in pygame yet, but is just the possible API. So it can't be benchmarked since it doesn't really exist. It's Vapour-ware ™, so only good for making clouds -- not websites.

Compared to the others*1 it has:
  • less code (measured in LOC, or # of characters)
  • simpler code (no need to write functions or classes).
  • JOYSTICK control


  • Note: this is a response to this series of posts about a basic REST application written in python.

    Starting with "Eric Florenzano's deliberately minimalist WSGI application illustrating a bare metal WSGI application with RESTful behaviour has drawn out from other Python web application framework communities a number of useful comparisons"

    1. Christian Wyglendowski's entry using cherrypy
    2. Tim Parkin's restish approach
    3. Grok showing real object persistence by Martijn Faasen.
    4. A Werkzeug solution also by Tim Parkin.
    5. Carlos de la Guardia provides a solution via repoze.bfg, which, like Grok, shows how Zope3 technologies can be used.
    6. Then mike Watkins does the same thing with qp http://mikewatkins.ca/2009/01/18/resty-applications-in-qp/
    7. this post (self post) where we add Joystick control to a Vapour-ware ™ REST framework.

    Sunday, January 18, 2009

    pygame port to S60 nokia phones.

    Jussi Toivola has done some more on his pygame port to symbian s60 -- which many nokia phones run.

    Here's some details of his progress on the port.


    >>> Jussi Toivola writes:

    new version is out(SVN 1844):
    http://jtoivola.googlepages.com/pygame_20090117_signed.sisx

    New features:
    - png, jpg, gif and tif image support.
    - Demo replaced with launcher application
    -- liquid example ported to s60
    -- Comes with initial pen\mouse support( no list scrolling yet )
    - Lots of build script configuration
    - Python embedded as a sis with byte-compiled libraries( PyS60 CE feature )

    Detected limitations:
    While implementing the launcher, I stumbled upon a problem with fonts.
    Symbian's c-library (estlib) does not allow multiple open file handles
    on a single file. This causes following code to fail on phone( works
    on emulator ):

    font1 = pygame.font.Font( None, 20 )
    font2 = pygame.font.Font( None, 30)

    On the second line pygame tries to open the default font file, but
    fails in doing so. I worked around this by caching the surfaces of
    rendered texts but it's good for static texts only. I don't know if
    OpenC handles this better. Caching optimizes the screen updates anyway
    so I'm not sure how severe limitation this actually is.

    Also there is no event sent if S60 device's screen orientation
    changes, thus it is not possible to handle it with pygame. Not with
    events anyway and in portable way.

    Sources:

    Sources are available at: svn://seul.org/svn/pygame/branches/symbian_s60

    The port is based on trunk revision 1760( pre 1.9.0 )

    Saturday, January 17, 2009

    pygame.tests and pygame.examples as packages.

    As mentioned in pygame.test - moving testing forward the pygame project has moved the tests into the main pygame package(Lenard did all the work). *You* should consider installing the tests for your package too! All the reasons for doing so are listed at pygame.test - moving testing forward ... but I'll repeat them here too:
    • More people will run the tests.
    • people can run the tests to see if everything works in their own programs.
    • Can run tests on a persons computer to see if everything in pygame+ your program is working.
    • Which driver/function combination works, or works fastest? Run tests and find out.
    • Testing a py2exe/pyapp generated binary is much easier.
    • Reuse of our testing enhancements for their own tests.
    • Reporting bugs would be easier. Since everyone could run unittests, since they will be installed everywhere pygame is installed.
    • Result submission of unittests easy. This would result in a much larger base of computers running the unittests and submitting problems. This would be opt in of course.
    • Make the testing stuff more a library, than a framework.
    • Allow people submit unittests more easily. Since they won't require a source release of pygame to write unittests. eg people using a windows binary install of pygame, or a ubuntu binary install can run and submit unittests.
    • Make testing easier for people. The easier it is, the more worthwhile testing is.

    >>> import pygame.tests
    >>> pygame.tests.run()

    However we also moved the examples into the main pygame package.

    When the examples were separate as part of the source code distribution, or installable with a separate installer, many people did not install them. Then they had trouble finding the examples.

    So now, people should be able to run examples like so:

    >>> import pygame.examples.chimp
    >>> pygame.examples.chimp.main()

    Both of these things should make pygame easier to use, and also increase the quality a lot.