[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

[Nathaniel Smith]

Nathaniel Smith <njs at pobox.com> added the comment:

@Nick:
> We're OK with the idea that installing a trace function might automatically turn off various compiler and interpreter managed optimisations

We're OK with assigning to locals() doing that too.

> What we're aiming to avoid is requiring that implementations make the assertion in "a = 1; locals('a') = 2; assert a == 2" pass at function scope, and if anything, we'd prefer to make it a requirement for that assertion to *fail*.

Why do you want it to fail? Given that it's already guaranteed to pass in some scopes (definitely in CPython, I'm not sure if it's in the language spec), and that we need to support mutations of f_locals for debugging, then this seems like a quixotic requirement. But if we do want it to fail, then we should make it fail obviously, e.g. by having locals() return a read-only mapping that raises an exception on mutation.

The only rationale I can understand here is the desire to leave options open for alternative implementations... but in practice all those alternative implementations can either support this just fine (because they have to to support pdb), or else they're MicroPython and have already stopped supporting locals() entirely so it hardly matters how CPython tweaks the details of the semantics.

> Requiring locals to actually *be* a write-through proxy (for all locals, not just cell references) would revert Python's semantics to the state they were in before the "fast locals" concept was first introduced, and we have no intention of going back there.

Why not? I don't think anyone has ever suggested that "fast locals" made Python's *semantics* simpler.

@Armin:
> Perhaps more importantly, I am sure that if Python starts supporting random mutation of locals outside tracing hooks, then it would open the door to various hacks that are best not done at all, from a code quality point of view.

I'm not saying that assigning to locals() is great style, but there are totally legitimate use cases (debugging), and there's nothing stopping those hacks right now. You *can* use tracing hooks, or there's this nonsense: https://gist.github.com/njsmith/2347382

Once Python commits to supporting something, then generally it exposes it in a pretty straightforward way; it's really unusual to put the feature in a non-obvious place and then make the obvious way subtly broken to punish people who try to use it.

@Nick
> - when do we update ordinary local variables? (this isn't broken, so we want to avoid changing it)

But as pointed out earlier in this thread, pdb's support for updating ordinary local variables *is* currently broken, and would be fixed by using a write-through proxy for f_locals: https://bugs.python.org/issue30744#msg297480

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________