-
-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Idea: event types are actual types #2759
Comments
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. |
Sub-classing The question, that I have, is how the library would behave when firing an event using event id? - Would it create normal |
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: |
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 ofEvent
? TheKeydownEvent
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:
This could be backwards compatible even, since each subclass could still export
.type
correctly to the old style constants (pygame.KEYDOWN
)The text was updated successfully, but these errors were encountered: