On Wed, Sep 12, 2018 at 03:58:25PM +0100, Jonathan Fine wrote: > My question is about correctly implementing of __params__ as a keyword > identifier, with semantics as in Steve B's code snippet above.
The semantics of Steve's code snippet are ambiguous. > Here's my question: Do you think implementing this requires the > avoidance of a race hazard? I don't know what "this" is any more. I thought Steve wanted an externally accessible fn.__params__ dict, as that's what he said he wanted, but his code snippet doesn't show that. If there is no externally accessible fn.__params__ dict, then there's no race hazard. I see no reason why a __params__ local variable would be subject to race conditions. But as you so rightly quoted the Zen at me for guessing in the face of ambiguity, without knowing what Steve intends, I can't answer your question. As a purely internal local variable, it would still have the annoyance that writing to the dict might not actually effect the local values, the same issue that locals() has. But if we cared enough, we could make the dict a proxy rather than a real dict. I see no reason why __params__ must be treated as special keyword, like __debug__, although given that it is involved in special compiler magic, that might be prudent. (Although, in sufficient old versions of Python, even __debug__ was just a regular name.) > Or perhaps it can be done, as I suggested, > entirely within the execution frame on the stack? Indeed. Like I said right at the start, there shouldn't be any problem for the compiler adding a local variable to each function (or just when required) containing the initial arguments bound to the function parameters. *How* the compiler does it, whether it is done during compilation or on entry to the function call, or something else, is an implementation detail which presumably each Python interpreter can choose for itself. All of this presumes that it is a desirable feature. -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
