Events as types

[gresm]

Closes #2759

• implement logic
• documentation
• tests
• stubs

[MyreMylar]

Are these changes intentional?

[gresm]

My meson plugin warned that using booleans with quotes is deprecated and I saw that everywhere else no quotes were used, so it's nothing important, should I revert this?

[MyreMylar]

This seems to work in my testing, per the original issue:

[MyreMylar]

This makes me slightly nervous!

[gresm]

I wanted to write something like this, but didn't want to add any dependency nor to have any copyright issues with using random hash algorithms taken from the internet, so I opted for coming up with my own "hashing" algorithm, which only requirement was to not create collisions for the existing names.

[MyreMylar]

OK, it seems to work in my testing without obviously breaking any of the existing ways events are used. I noted a couple of minor things.

@ankith26 should probably look it over as they've spent much more time digging around in event.c than I have.

👍 🎆 🎉

[ankith26]

Hello!

This seems like a lot of hard work! I wish you had discussed it more before going ahead and implementing this.

I assumed that the issue is to be tackled in the long term (like, post the SDL3 migration) so I didn't really comment on the issue yet.

I think it would be much simpler to implement as much as possible in pure python code, and having minimal C code changes. event.c is pretty messy as it is, and IMO we should be focused on making it more maintainable by offloading more things to the python side.

So, something like minimal _event.c exporting the core internal functionality provided by SDL, and event.py built on top of that with all the subclassing logic implemented.

[gresm]

I think it would be much simpler to implement as much as possible in pure python code, and having minimal C code changes. event.c is pretty messy as it is, and IMO we should be focused on making it more maintainable by offloading more things to the python side.

@ankith26 I agree that event.c is already messy, but I worry that using pure python implementation for implementing event classes would be too slow (I didn't check this). I think that splitting the logic between pygame._event and pygame.event is a good idea, but something far outside the scope of "Events as types PR" and would require its own pull request.

[Starbuck5]

I think it would be much simpler to implement as much as possible in pure python code, and having minimal C code changes. event.c is pretty messy as it is, and IMO we should be focused on making it more maintainable by offloading more things to the python side.

@ankith26 I agree that event.c is already messy, but I worry that using pure python implementation for implementing event classes would be too slow (I didn't check this). I think that splitting the logic between pygame._event and pygame.event is a good idea, but something far outside the scope of "Events as types PR" and would require its own pull request.

I think that there will be some opportunities in the future to rewrite things in Python and have them be both easier to maintain as well as faster. As the faster-cpython team gets the interpreter faster, the overhead of going between C and Python will be more significant.

In the below test script, Python is faster than C to implement a pygame API function (in 3.12 but not in 3.9, which are the only versions I tested)

Test script

import pygame
import random
import time

random.seed(36)

use_python = False


class Obj:
    def __init__(self, x, y, w, h):
        self.xa = pygame.Rect(x, y, w, h)


objs = [
    Obj(
        random.randint(-100, -100),
        random.randint(-100, 100),
        random.randint(-100, 100),
        random.randint(-100, 100),
    )
    for _ in range(5000)
]

start = time.time()


class Rect(pygame.Rect):
    def collideobjectsall(r, objects, key):
        colliding_indices = r.collidelistall([key(obj) for obj in objects])
        return [objects[colliding_index] for colliding_index in colliding_indices]


if use_python:
    r = Rect(-20, -20, 100, 100)
    for _ in range(1000):
        colliding_objs = r.collideobjectsall(objs, key=lambda e: e.xa)


else:
    r = pygame.Rect(-20, -20, 100, 100)
    for _ in range(1000):
        colliding_objs = r.collideobjectsall(objs, key=lambda e: e.xa)


print(time.time() - start)

List comprehensions are just too good.

[gresm]

@Starbuck5 this looks interesting, but isn't a good measure for speed comparison in this case. I assume that python version could probably have similar speed as this C implementation, in some places probably a bit slower, but I'm not sure if it is worth re-implementing this in python, is there enough interest for it, that it would make sense for me to work on this. Is there enough interest in this for me to go on writing a new implementation, when there is one already?

[ankith26]

I think we cannot make performance claims either way without actual benchmarking or implementation.

But one thing is for certain, event handling is typically orders of magnitude faster than drawing/rendering and updating the display (especially for large displays and software rendering) for each frame, so we aren't exactly in a performance critical area.

What I personally want to prioritize, is the SDL3 porting in this module that comes with its own refactorings. I have a patch or two lying around for this module since like over 2 years, and I've been basically waiting for SDL3 to kinda stabilize in its API.

I do not want to be adding any new API to event till we are sure that the SDL3 API is stable and whatever we introduce must be compatible with it.

[gresm]

@ankith26 Understandable, this is another reason why splitting event logic between _event and event would be useful, as it would decrease logic in _event.c and would make transitions easier. That's enough for me to see this worth the effort.

[gresm]

Events as types in python is ready for review (#3121).