The very first thing you need to do in order to implement this is to define the semantics clearly. At the moment, you’ve not done that.
The when
keyword create a thread that observe the variables in the condition. If it changes, it will check the condition again. If the condition is fulfilled, it will execute the indented code below.
What do you mean by “variable” here? If the when construct is within a function, can it access local variables of the function? What about variables declared nonlocal
or global? Can you observe an instance attribute (obj.something
)? What about an element of a collection (some_list[2]
)? What about properties (attributes that are computed)?
Are conditions other than equality allowed? What about !=
or <
? What about more complex checks like x % 2 == 1
?
The definition says “when the variable changes” - there’s no mechanism in Python to trigger an action when a variable changes - do you plan on adding one, and if so how will that interact with optimisations like dead code elimination, and how do you plan on it not imposing a performance cost on the vast majority of variable modifications that don’t need to trigger an action?
Or if you’re just planning on a background thread periodically checking the value, how often does the thread check the monitored value? Can the user change this? What if it’s too fast (or too slow) for the application’s requirements? Can the user stop the monitoring? Or pause it? What if the variable changes from the trigger value to another value and back again in between two checks? Will that value change simply be missed? How will users be able to rely on a mechanism that might simply not work some times?
Does the monitoring thread persist after the function that contains it? Consider:
global_val = 0
def monitor_val(start_val):
x = start_val
when global_val == 19:
x += 1
print(x)
monitor_val(12)
global_val = 19 # The print needs to access the local variable x, which no longer exists...
global_val = 1
monitor_val(4)
global_val = 19
# Will *both* instances of the when block, from the two calls to monitor_val, be triggered?
# Will it therefore print 14 and 5? Just one? Which one?
How does the thread have access to x?
You have to answer all of these questions - language features can’t be specified in terms of things that “the developer should be cautious about”. It’s fine to have clearly and precisely defined semantics that result in undesirable behaviour like infinite loops, but not to have semantics that say such things “might” happen, without being clear how or why.
Personally, I think this proposal is potentially interesting as a possible (3rd party) library, offering a different way to do “background tasks”, but it’s currently far too under-specified. And it stands no chance in its current form of being accepted as a language feature. Quite apart from the unclear specification, which itself would be enough to kill it, threads in Python are currently implemented by library code, not by language constructs. I can’t see this being the mechanism that gets chosen as the fundamental (i.e., language-level) interface to threads.