Get rid of perform()

[itamarst]

I feel like calling perform() in non-test code is a problem, insofar as you have to call it at arbitrary points in the code, and beyond those boundaries the benefits go away.

A hand-wavy counter-proposal: perform() is done automatically in Effect.__init__... except when disabled by running code in a with no_effect: context manager, in which case the current API applies.

[radix]

If you're concerned about losing the benefits of effect above the calls to perform(), I don't understand why you'd suggest making Effect.init do the performance -- this would make all code that creates an Effect not purely functional.

I understand that while migrating a codebase from deferreds (or any kind of IO) to effect will require putting a call to perform() call at every boundary, eventually the number of these calls should be reduced as more and more of your code becomes purely functional. perform() is a necessary part of separating pure and impure code, being the line of demarcation between them, which is intrinsic to the whole point of the effect library.

[itamarst]

Running code is always side-effecty (and therefore by definition non-functional) when it's running; a program without side effects is useless. I want my code to be easy to reason about and test when I am writing the code. My strawman proposal would allow making code functional when testing. For running code, does it really matter if perform() is called at a lower or higher level of the stack, given it's going to happen regardless?

(Certainly if you're writing Haskell and you've got a compiler that can take advantage of functional code for parallelism or STM or whatever then that's great... but this is Python.)

[itamarst]

And to clarify, I'm worried about losing the benefits to unit testing because of perform() scattered throughout the code. Which is what my (again, very hand wavy) proposal is trying to address. I want to be able to write "normal" Python code... but still be able to write unit tests that let me get at the intent without having side effects.

[radix]

so, I'm willing to humor this conversation somewhat, but I will point out the description of the Effect project:

effect isolation in Python, to facilitate more purely functional code

If you're not interested in writing purely functional code, then I don't think Effect is what you want. I made it the one-line description of this project for a reason :)