Alright, so you get numbers from a json file in a ftp servers, you use scipy.newton to perform root finding on it, but needs the number of steps to be outputted as well (which newton() doesn't return), and you will save the result in a postgres table.
All this should be send to a task queue, triggered by a call to your REST API.
"Railway Oriented Programming"[1] is a (functional) technique to achieve purity despite steps that could result in error states. The error states are hidden/pushed to the very edges/end of your code. So you can focus on the "happy state" for the main business logic:
> Many examples in functional programming assume that you are always on the “happy path”. But to create a robust real world application you must deal with validation, logging, network and service errors, and other annoyances.
> So, how do you handle all this in a clean functional way?
> This talk will provide a brief introduction to this topic, using a fun and easy-to-understand railway analogy.
Most of your counter example needs integration tests to test properly anyhow - not really a good point.
If you can give up encapsulation (which IMO isn't actually that useful in practice) and in return, your program becomes 95% functional, that seems like a really good tradeoff.
What's your definition of "pure function". Apparently not "pure function" in the sense of "pure functional programming", because if that were so, your claim would just be wrong. Counterexample: "printToConsole: IO[null]": is a pure function but still not easy to test.
The definition of "pure function" I'm familiar with from functional programming has no side effects including I/O. Assuming 'printToConsole' is performing I/O, you're describing a impure function.
Then you have not understand what (pure) functional programming is and how it works.
I recommend you to have a look at Haskell, probably the most famous language for enforcing only pure functions in your program. And I took this example from Haskell.
While there is an important sense in which even IO values in Haskell are still pure values, it is not helpful in the case of testing.
$ ghci
GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help
Prelude> putStrLn "hello" == putStrLn "hello"
<interactive>:1:1: error:
• No instance for (Eq (IO ())) arising from a use of ‘==’
• In the expression: putStrLn "hello" == putStrLn "hello"
In an equation for ‘it’: it = putStrLn "hello" == putStrLn "hello"
If you want to test your IO code, and you should, you still have to test them from the perspective of them actually executing in the real world. There's no way to test them as pure values. The snippet above is only the beginning of your problems if you wanted to do that, but it a plenty sufficient problem on its own. In addition to the obvious problem that it points out that IO values are already not comparable to each other in the naive sense, there's also the more philosophical problem that the IO values are your programs, so even if you could run the test I show above, on more complicated expressions, your tests would be asserting that you wrote the program you thought you wrote, not that the program you wrote does what you think it should do.
First thing to do: Stop using class. Ask yourself first: Should i use a class here and there ?
Wait, i miss something here: Writing pure functions is hard ?