It looks like on windows the build shell is constrained to be cmd.exe.
SlickEdit doesn't have built in logic to deal the logical boundary between the Windows environment and WSL. (or any other type of hosted VM). So while you can slightly cheese it by doing something like "wsl.exe python3 /some/py.file" to run python under WSL, when SlickEdit needs to expand paths for project tools, set the working directory, etc..., they're going to be windows format paths, and not unix paths that reference the mount layout of your WSL setup. So that will break a lot of things.
As a short example: you run a python program with that wsl.exe command, and there's a syntax error. You hit your keybinding to go to next-error, and at best you get prompted for the source file location, because it will try to interpret the source file in the error message as a windows path.
As far as debugging python goes, I think the path issues would make it so you can't start debugging the program by hitting F5. If you can make TCP connections from the windows side into the WSL side, then you could treat it as the remote debugging case which is described in the manual.
While it's possible to go from the other direction and run SlickEdit on the WSL side (if you have an XServer running in windows), it's not a configuration we test with. We know some customers have done it, and reported some windows not giving focus to the right control when it comes up. (not super surprising, we have seen similar with less common window managers on Linux). Microsoft is going to be providing a XWindows server for WSL that can support graphics acceleration, it's in preview now. I am interested in seeing how we work with that, but I can't predict if it's a configuration we'll test with or not.