Idea: event types are actual types

[Starbuck5]

This isn't fully developed, mostly putting this up so it doesn't get forgotten

Currently, event types don't have great autocomplete or type hinting correctness, because they are very generic. They are all instances of Event.

What if a pygame.KEYDOWN event, for example, was an instance of a KeydownEvent class, a subclass of Event? The KeydownEvent class could have its own docstring, type stub for properties, properties docstrings with descriptions, and it could all be type checked effectively.

In a game loop, one would do a bunch of isinstance() calls, rather than event.type checks. For example:

if isinstance(event, pygame.KeyDownEvent):
    if event.key == pygame.K_1:
        window.maximize()

This could be backwards compatible even, since each subclass could still export .type correctly to the old style constants (pygame.KEYDOWN)

• How would this work elegantly with custom event types made by users?
• Is this a pygame-ce 3 level thing?

[robertpfeiffer]

I looked into a similar thing: Have all key/event enums be python enums. Unfortunately, it's difficult to translate between python enums and C.

[gresm]

How would this work elegantly with custom event types made by users?

Sub-classing Event class could do the trick. The id could be automatically generated at class creation (this can be even implemented in python using __init__subclass__ and setting a class property).

The question, that I have, is how the library would behave when firing an event using event id? - Would it create normal Event class, or would it lookup the subclass and attempt creating its instance?

[gresm]

Is this a pygame-ce 3 level thing?

I think that I've implemented this without breaking compatibility with any code besides that which uses bad ways of checking type of instance, like: type(obj).__name__ == "Event" or obj.__class__ is Event.