Separate namespace for raygui, etc

[electronstudio]

I can't see any easy way to do this for raylib module - it would require cffi build separate module for raygui.

However we can do whatever we like in the pyray wrapper module, so we could move them into a pyray.raygui submodule or duplicate them in both pyray and pyray.raygui. Just need to identify which items are from raylib.h and which from raygui.h. Probably the api json parsing could do that.

Could also do for physac. Not sure if anyone really wants this but would make it easier to find functions perhaps?

[3demax]

I've done a lot of python coding and some C for the last 14 years or so. However, I'm new to python bindings, but I'd be interested in starting a separate library for physac. It seems like a good first target, being not too big but still useful.

[electronstudio]

Well I (obviously) think CFFI module is the easiest way to bind a C library, but there are also older FFI libraries you could use: Ctypes, Cython. And there is a newer one too, https://hpyproject.org/

[DevTwilight]

I think Pyray modules such as raygui, rlgl, raudio, rpng, rres, and raymath should be separated from the core and organized as submodules.

They could be accessed using a namespace-like structure, for example:

• pyray.math
• pyray.audio
• pyray.gui

This would improve clarity, structure, and usability, especially for larger projects.

[electronstudio]

It makes sense for anything that has its own header file, like raygui.h, to be in its own module, but I'm not sure about splitting raylib.h into e.g. audio and video when the namespaces dont exist in the original.

The easiest way to do this might be to just duplicate everything into every submodule, so we don't need to access raylib.json at runtime, and then generate .pyi files at build time (where we already use raylib.json) that only list the appropriate functions for each.

[DevTwilight]

@electronstudio Thanks for the response! Just to clarify — I wasn’t suggesting splitting up raylib.h itself into artificial submodules like audio or video. I agree that wouldn’t align with how the core API is structured in C.

What I meant was organizing the extra Raylib libraries like raygui, raymath, raudio, rlgl, rres, and rpng. These are already separate header-only libraries outside of raylib.h, and many of them are included optionally or used internally.

Since they’re already logically and physically distinct in C (e.g., raymath.h, raudio.h, etc.), it seems natural to reflect that separation in the Python bindings — for example:

import pyray.math    # raymath
import pyray.audio   # raudio
import pyray.gui     # raygui

This kind of structure improves clarity, organization, and usability without altering or fragmenting the core Raylib API. It also keeps things clean for larger projects where modularity matters.

For reference, here’s the official section on the extra libraries:
🔗 raylib extra libraries