TL,DR: The SDL2 event/render system is not yet thread-safe, but you can overcome this limitation by using OpenGL to decouple the renderer system from your application (and then perform all rendering in a separate thread using only OpenGL functions). In this method, you still have a single event queue.
Another way is to use multiple processes (e.g. using PySDL2 and Python's multiprocessing
module, or a C/C++ program that launches two sub-processes), and follow the same dual-window method outlined below (where each window has it's own event queue, but one window is hidden and is only polled to check for user input). One process will handle drawing and the other input, and application state changes and events are communicated between both processes using a pipe or thread-safe queue.
It's generally not recommended to separate render/input/game logic into different threads since it greatly complicates things under the hood, and you need to ensure data concurrency and thread synchronization (although SDL2 does indeed provide what you need to accomplish this). That being said, if you do need to separate input/rendering - and in this case, I agree that would be the most logical thing to do - it is possible to do using SDL2 threads (as well as Python threads if you're using PySDL2) and OpenGL.
There are two approaches to accomplishing this, one with a single-window and another with a double-window.
With a single window, create your OpenGL context/window with SDL2, then pass the OpenGL context to a new thread that will perform only rendering. It needs to safely notify the main thread when to call SDL_GL_SwapWindow and block until it's done (you can still keep polling events for the window even if you don't call GL_SwapWindow), but so long as you ensure only one thread is calling OpenGL functions at once, there is no problem doing this, even cross platform.
Using the double-window approach allows you to fully decouple all OpenGL API/rendering calls from the main loop, by using the main loop to create a hidden overlay window that captures the keyboard/mouse input, and continually polls for input/window events. This way you don't need to stop for any OpenGL calls, and so long as your application state is thread-safe, you can pass any relevant window events to the GL window in a queue.