Nathaniel Smith <n...@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 <rep...@bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
