Not currently on a concrete roadmap, but the architecture was deliberately left open for this. The C++ code generator is literally named cpp_generator.cpp, not just generator.cpp, specifically leaving room for other backends later.
One clarification on the "low-level speed from Python" part though: I think the more useful path there isn't a separate Python code-generator (which would mean Python itself doing the AST walking, probably giving up most of that speed), but Python bindings over the generated C++ classes, something like pybind11 or nanobind wrapping the AST and walker types. That gets you both: parse and walk at C++ speed, call it from Python. A true Python backend would be a different, slower thing aimed at a different use case (prototyping grammars without a C++ toolchain, say).
No promises on timeline, but if there's real interest I'd probably go the bindings route first.
One clarification on the "low-level speed from Python" part though: I think the more useful path there isn't a separate Python code-generator (which would mean Python itself doing the AST walking, probably giving up most of that speed), but Python bindings over the generated C++ classes, something like pybind11 or nanobind wrapping the AST and walker types. That gets you both: parse and walk at C++ speed, call it from Python. A true Python backend would be a different, slower thing aimed at a different use case (prototyping grammars without a C++ toolchain, say).
No promises on timeline, but if there's real interest I'd probably go the bindings route first.