On 08/02/2020 11:49 am, Nick Coghlan wrote:
Unfortunately, the simplifications you propose would be backwards
incompatible - it's existing behaviour that there's a real shared dict
(even on optimised frames) where arbitrary extra attributes can be
stored (even though they don't become accessible as Python variables).
I don't want to make frame objects any bigger than they already are,
so the natural solution is to store the mapping proxy as `f_locals`,
and then bypass the proxy in order to make `PyEval_GetLocals` still
"work" (at least as well as it ever did).
The proposed changes in PEP 558 are also backwards incompatible.
I thought that was the point. The current implementation is broken in
weird ways and we want to fix that. Since we need to break backward
compatibility anyway, why not do it in a way the makes the behaviour as
well defined and maintainable as possible.
I think that PEP 558, as it stands, is still a bit fragile because of
the handling of cycles between the locals proxy and the frame.
PyObject_GetAttr(string) also doesn't do that same thing as the
proposed C functions, since it invokes the Python descriptor
machinery. (Note that the discussion at
https://discuss.python.org/t/pep-558-defined-semantics-for-locals/2936/
is more up to date than the PEP text where the C API is concerned)
`PyObject_GetAttr("attr")` has the same semantics as the Python operator
`x.attr` which is under the control of `type(x)`, in this case the frame
object class. The descriptor protocol is irrelevant.
The reference to tracing mode dependent semantics puzzles me, as that
was removed in December:
https://github.com/python/peps/commit/54888058ce8ad5257114652d9b41e8d1237b8ef9#diff-5abd04ea7e619670b52d61883873e784
That was my misreading. The behaviour of `f_locals` in the PEP is not
very clear, as it is buried in the discussion of CPython changes.
Could you add it to the proposal section?
Cheers,
Mark.
Cheers,
Nick.
On Wed, 22 Jan 2020 at 21:59, Mark Shannon <m...@hotpy.org> wrote:
Hi,
First of all I want to say that I'm very much in favour of the general
idea behind PEP 558. Defined semantics is always better than undefined
semantics :)
However, I think there are a few changes needed:
1. Don't add anything to the C API, please.
Frame attributes can be accessed via `PyObject_GetAttr[String]`.
2. Don't make the behaviour dependent on whether "tracing" is turned on.
Doing so forces debuggers to use sys.settrace which is horribly
slow. It also makes the implementation more complex, and has no benefit
AFAICT.
3. Don't store write-through proxies in the frame, but make proxies
retain a reference to the frame. This would reduce the size and
complexity of code for handling frames. Clean up of the frame would
occur naturally via reference count when all proxies have been reclaimed.
The proposed implementation is hard to reason about and I am not
confident that it will not introduce some new subtle bugs to replace the
ones it seeks to remove.
Any implementation that has functions with "Borrow" and "BreakCycles" in
their names makes me nervous.
A simpler conceptual model, which I believe could be made reliable,
would be:
No change for non-function frames (as PEP 558 currently proposes).
Each access to `frame.f_locals` (for function frames) should return a
new proxy object.
This proxy object would have dict-like, write-through semantics for
variables in the frame. For keys that do not match variable names, an
exception would be raised. This means that all proxies for a single
frame will have value equivalence; object equivalence is not needed.
I.e. for a frame `f`, `f.f_locals == f.f_locals` would be True, even
though `f.f_locals is f.f_locals` would be False.
Cheers,
Mark.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/TSHCB4ZHC4XUVGJ3MX4D7HCHMTB6WROD/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/J7374C46BOSR5WK23STKIUNPTYEWKPWZ/
Code of Conduct: http://python.org/psf/codeofconduct/
