Mythical arcade @GAMe api

game.py

### In all of these cases, *we* make the pyglet window, store it
### "somewhere" (class variable, closure, thread local), and provide
### it as an argument to registered stuff that we (not pyglet) are
### responsible for calling.

### Imperative example. draw_point is an API which adds the arguments
### to a list of draw_point things to run. game.run() makes a window,
### starts render, and calls all the things queued up. In *theory* we
### could implicitly do batching.
from arcade import game, color

game.draw_point(100, 200, color.BLUE, 5)
game.run()  # Defaults to a 100x100 window, some color


### Function example. Registers a callback.
from arcade import game, color

@game.on_draw()
def say_hello(world):
    world.draw_point(100, 200, color.BLUE, 5)

game.run(height=200, width=200)  # Pass window settings


### Class-based example.
from arcade import game, color, key

@game.world(height=200, width=200, background_color=color.BLUE)
class MyWorld:
    def __init__(self):
        self.sprites = "etc."

    @game.on_draw()
    def make_text_funny_name(self, world):
        # The world is passed in, vs. self being the window instance
        world.draw_point(100, 200, color.BLUE, 5)

    @game.on_key_press(key=key.UP)
    def move_a_little_up(self, world, modifiers):
        # This callback is only called for the correct key, but
        # pass in modifiers for further refinement
        pass

game.run()

This looks a good track do go down. I'm wondering how Sprites can fit in.

Do you see PEP 557 as an option to store game data in a functional programming setup? Or is that not related.