[issue19431] Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError()
New submission from STINNER Victor: (Copy of an email) Georg Brandl via python.org Am 29.10.2013 01:19, schrieb victor.stinner:
http://hg.python.org/cpython/rev/4ef4578db38a changeset: 86715:4ef4578db38a user: Victor Stinner <victor.stinner@gmail.com> date: Tue Oct 29 01:19:37 2013 +0100 summary: Issue #18408: Add a new PyFrame_FastToLocalsWithError() function to handle exceptions when merging fast locals into f_locals of a frame. PyEval_GetLocals() now raises an exception and return NULL on failure.
You'll have to either make this private or document it. ---------- assignee: docs@python components: Documentation messages: 201618 nosy: docs@python, georg.brandl, haypo, pitrou priority: normal severity: normal status: open title: Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError() versions: Python 3.3, Python 3.4 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue19431> _______________________________________
STINNER Victor added the comment: c_api_frame.patch: document some C functions of the frame object in the C API. ---------- keywords: +patch Added file: http://bugs.python.org/file32537/c_api_frame.patch _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue19431> _______________________________________
Cheryl Sabella added the comment: Victor, Should there be a PR for this? ---------- nosy: +csabella _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue19431> _______________________________________
Serhiy Storchaka added the comment: PyFrameObject already is documented in Doc/c-api/veryhigh.rst. PyFrame_GetLineNumber() already is documented in Doc/c-api/reflection.rst. PyFrame_FastToLocals() and PyFrame_LocalsToFast() are not documented and have weird interface. I think the use of them should be discouraged. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue19431> _______________________________________
STINNER Victor <victor.stinner@gmail.com> added the comment:
Should there be a PR for this?
Feel free to create a PR from my old (4 years old) patch. Just mention my name in the commit message please. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue19431> _______________________________________
STINNER Victor <victor.stinner@gmail.com> added the comment:
PyFrame_FastToLocals() and PyFrame_LocalsToFast() are not documented and have weird interface. I think the use of them should be discouraged.
I suggest to document them, but explain in the documentation that they must not be used :-) ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue19431> _______________________________________
STINNER Victor <victor.stinner@gmail.com> added the comment: Ah, PyFrame_GetLineNumber is now documented at Doc/c-api/reflection.rst. But PyFrame_New() is still not documented. So my patch is not completely useful. @Cheryl: Maybe convert the PR without PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError(). ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue19431> _______________________________________
Cheryl Sabella <chekat2@gmail.com> added the comment: Thanks Victor and Serhiy.
@Cheryl: Maybe convert the PR without PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError().
If I only convert PyFrame_New() then I would need to add it to as existing page since the patch created a new page for Frame Objects. I think the right place would be under the current PyFrameObject in Doc/c-api/veryhigh.rst? Thanks! ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue19431> _______________________________________
STINNER Victor <victor.stinner@gmail.com> added the comment:
If I only convert PyFrame_New() then I would need to add it to as existing page since the patch created a new page for Frame Objects. I think the right place would be under the current PyFrameObject in Doc/c-api/veryhigh.rst?
Not, it's a very high level API, it's a low level API which should be referenced in the concrete.rst page, as I didn in my patch. I think it's ok to have a page with only two functions: PyFrame_New() and PyFrame_GetLineNumber(). Move https://docs.python.org/dev/c-api/reflection.html#c.PyFrame_GetLineNumber into your new doc, but leave something like "See also :c:func:`PyFrame_GetLineNumber`." there. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue19431> _______________________________________
STINNER Victor <victor.stinner@gmail.com> added the comment: Serhiy: how are you supposed to modify local variables of a frame when these variables are stored in "fast locals"? Even if it's a rare useful, I think that it's ok to expose PyFrame_FastToLocalsWithError(), and maybe also PyFrame_FastToLocals(). It is useful you want write a debugger in pure C, and don't want to bother with fast locals special case. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue19431> _______________________________________
Serhiy Storchaka <storchaka+cpython@gmail.com> added the comment: frameobject.h is not included in any header file. Some effort was spent for avoiding including it in ceval.h, genobject.h, pystate.h and traceback.h. The whole content of frameobject.h is not available in the limited API. I'm not sure about the status of this API. This is not a very hight level API, but rather a very low level API. If document it, it should be documented on a separate page or on a page together with other low-level API.
Serhiy: how are you supposed to modify local variables of a frame when these variables are stored in "fast locals"?
Currently you should call PyFrame_FastToLocalsWithError(), modify directly f_locals, and call PyFrame_LocalsToFast(). This is very low-level manipulation. It exposes implementation details (at least you need to access PyFrameObject attributes directly). It should be documented that the most of PyFrame_* API is low-level and implementation specific. PyFrame_GetLineNumber() is an exception. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue19431> _______________________________________
STINNER Victor <victor.stinner@gmail.com> added the comment:
Currently you should call PyFrame_FastToLocalsWithError(), modify directly f_locals, and call PyFrame_LocalsToFast().
When happens if PyFrame_LocalsToFast() isn't called? Does it crash or is it just slower? ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue19431> _______________________________________
João Sebastião de Oliveira Bueno <gwidion@gmail.com> added the comment: This discussion is fresh, so maybe it is worth asking here prior to python-ideas: In Python we can change any global variable, object attribute or mapping-value with function calls. Locals and nonlocals are the only exceptions and from time to time that gets in the way of clever oneliners, and it is just plain asymmetric. What do you say of adding a wrapper to this as an oficial Python function in the stdlib? Maybe inspect.setlocal() that could set f_locals and call this?? That would provide a workaround to the asymmetry that locals currently experiment. It would not impose any extra security risks, since this can be called via ctypes already, and also it is not any more subject to abuse than setattr or globals()[...] = can already be abused. ---------- nosy: +João.Sebastião.de.Oliveira.Bueno _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue19431> _______________________________________
STINNER Victor <vstinner@redhat.com> added the comment: It seems like these functions should be documented, so I close the issue. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue19431> _______________________________________
Change by STINNER Victor <vstinner@redhat.com>: ---------- resolution: out of date -> wont fix _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue19431> _______________________________________
STINNER Victor <vstinner@redhat.com> added the comment: I closed the issue because we decided to not document the function, but I'm still interested to mark the API is private. Such change is more sensitive, so I added it my larger "New C API" project which works on finding a way to deprecate functions and provide maybe helpers for backward and forward compatibility: https://pythoncapi.readthedocs.io/bad_api.html#for-internal-use-only ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue19431> _______________________________________
participants (4)
-
Cheryl Sabella -
João Sebastião de Oliveira Bueno
-
Serhiy Storchaka
-
STINNER Victor