New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError() #63630
Comments
(Copy of an email) Georg Brandl via python.org Am 29.10.2013 01:19, schrieb victor.stinner:
You'll have to either make this private or document it. |
c_api_frame.patch: document some C functions of the frame object in the C API. |
Victor, Should there be a PR for this? |
PyFrameObject already is documented in Doc/c-api/veryhigh.rst. PyFrame_FastToLocals() and PyFrame_LocalsToFast() are not documented and have weird interface. I think the use of them should be discouraged. |
Feel free to create a PR from my old (4 years old) patch. Just mention my name in the commit message please. |
I suggest to document them, but explain in the documentation that they must not be used :-) |
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(). |
Thanks Victor and Serhiy.
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! |
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. |
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. |
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.
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. |
When happens if PyFrame_LocalsToFast() isn't called? Does it crash or is it just slower? |
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. |
It seems like these functions should be documented, so I close the issue. |
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: |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: