Detecting if state is possibly mutated by a function

[anadon (Josh Marshall)]

I’m writing some meta-programming code, and for this I have a Reader Lock and a Writer Lock to guarantee concurrency safety. At the moment, I have to use the Writer Lock for all calls because some function calls could mutate state.

It would be great if there were a mechanism to report whether the function mutates external state, internal state, both internal state and external state, or does not mutate. By external state I mean state anywhere that isn’t like the function’s containing class or anywhere in the case of a module level function. By internal state, I mean something like the state on a class from one of that class’s functions. I’m not going to pretend like I have perfect clarity here. I don’t. But something like this would be nice.

Is there a way to accomplish this that I’m not aware of, prior work I’ve been unable to find, or would anything of the sort require something on the order of a PEP?

[Polandia94 (Pablo Nicolás Estevez)]

There was a interesting discussion about the complexity on pure functions on:

Static typing: Specify if function is pure

The other day a colleague and I were talking about how it would be nice to specify is a function has a side-effect or not for type checking. I really liked the idea and figured I’ll see if there are more people around here that would like it to. Quick Background A pure function is a function without side-effects. It will always return the same value given the same input parameters. An impure function has side-effects and thus is somewhat unpredictable when it comes to what it does. Examples…

[anadon (Josh Marshall)]

The thread seems to really spiral, but it did provide some insight. From this, I believe a PEP introducing new builtins for pureread(), purewrite(), and purefunc() would meet what is needed. I’m going to start a new discussion about some things I’d like to do so I can gather some feedback on how they ought to be accomplished.

[hprodh]

In the same scope but maybe slightly off topic, I made this thread a while ago

Decorator @innerscope to prevent access to outer scope objects

The use-case for this proposal is not necessarily regarding inclusion in final code… But is more focused on easing coding, especially when refactoring or passing code from a module to another. The proposal is to create a @innerscope decorator (I assume within the inspect module (?)), in such a way that linters will show a warning when a decorated function accesses some outer scope object (also possibly an exception can be raised (?)). from inspect import innerscope a = 1 @innerscope def func(…

The innerscope decorator works as a flake8 plugin, it is not exactly a purity checker but is able to prevent outer access and also acts as a “hygienization refactoring multitool”.
I used it a bit and it was quite handy, yet I had problem of IDE slowing down when inspecting huge code and I switched to ruff, which does not supports external plugin creation.

What I mean here is that this way (the innerscope decorator) is perfectly doable, extendable, flexible, low-maintainance and paradox-free (regarding the uncertainties of the definition of ‘purity’). Its drawback is the cpu cost, I hope it might be possible in ruff some day.