Why not make Joystick a class like the rest? Seems simpler and prettier than dealing with JoystickTypes all over the place.

Would it be better for Clock to have an__init__ and a generictp_new rather than a "new" factory function, likeEvent andChannel?

To get rid of the failing setup.py lint CI, you can runsetup.py format, which black and clang-format installed.

I got my hands on a linux laptop with a builtin webcam, so I did that one as
well. I was still not able to test it on windows, so it would be nice if
someone could double check if everything is working as it should.

Why not make Joystick a class like the rest? Seems simpler and prettier than
dealing with JoystickTypes all over the place.

Because the joystick function does not always always construct a new object, but
might return an already created one. I was not sure how to implement that,
without changing a lot of code, and possibly breaking some things.

Would it be better for Clock to have an__init__ and a generic tp_new
rather than a "new" factory function, like Event and Channel?

You are right, I changed it.

To get rid of the failing setup.py lint CI, you can run setup.py format,
which black and clang-format installed.

Ah. Yeah, I forgot to do it again.

Because the joystick function does not always always construct a new object, but
might return an already created one. I was not sure how to implement that,
without changing a lot of code, and possibly breaking some things.

We could override__new__ to return the new or old instance?

I don't want to merge this in with the current JoystickType documentation changes, because it makes it seem more complex and exposes that type as part of our API, when we might not want that.

I'd prefer the joystick status quo.

Everything else looks good, but I'll be sure to test webcam on Windows.[It still works]

For the failing format status, you can rebase the branch against main. It's because black updated, and so now all the in progress branches will potentially get a few unrelated changes. But novial put through a PR that fixes it in main, if you can rebase.

I don't really prefer status quo, I prefer things documented as accurate to the implementation as possible. We could also investigate implementingJoystick.__new__, I believe if the type is immutable, there should be no problem if__new__ returns a new reference to an existing object

@ankith26 I have to confess my objection originally stems from it making the docs ugly.

But we haven't gotten any issues with the status quo, unlike the Event status quo which kicked off this PR.

If we haven't decided to go with JoystickType or turn Joystick into a class of its own, it shouldn't be merged with the rest of this PR. I believe everything else is good.

Sorry, there's a conflict now with _camera.c because I merged another PR.