[issue46356] [C API] Enforce usage of PyFrame_GetBack()

[STINNER Victor]

STINNER Victor  added the comment:

This issue has been fixed by bpo-46836:

New changeset 18b5dd68c6b616257ae243c0b6bb965ffc885a23 by Victor Stinner in 
branch 'main':
bpo-46836: Move PyFrameObject to pycore_frame.h (GH-31530)

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46356] [C API] Enforce usage of PyFrame_GetBack()

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46356] [C API] Enforce usage of PyFrame_GetBack()

[STINNER Victor]

STINNER Victor  added the comment:

I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46356] [C API] Enforce usage of PyFrame_GetBack()

[STINNER Victor]

STINNER Victor  added the comment:

> I don't know how we can stop people from using them though.

The first option is to promote helper functions to abstract access to the 
PyFrameObject structure.

The second option is to make the whole structure opaque and enforce the usage 
of helper functions. Before being able to do that, we need to prepare Cython 
and a few more popular C extensions for that. Right now, Cython still has a lot 
of code accessing directly PyFrameObject members.

Well, we can discuss that in bpo-40421 ;-)


> If they don't know better than pulling data out of undocumented internal 
> struct, then I'm not sure an underscore prefix is going to help. It won't do 
> any harm, though.

I propose to rename f_back to trigger a build error for existing C extensions 
which access it directly. So developers have to decide how to handle the 
change: access the renamed member, or read the doc and use a better way, call 
PyFrame_GetBack() :-)

I dislike that this incompatible change is "silent" and that developers may 
only notice the change in production, when it's too late.

Or maybe most C extensions have a a good test suite and will notice the change 
before it's too late.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46356] [C API] Enforce usage of PyFrame_GetBack()

[Mark Shannon]

Mark Shannon  added the comment:

f_lineno is not part of the API. No field in PyFrameObject is.

I don't know how we can stop people from using them though.

If they don't know better than pulling data out of undocumented internal 
struct, then I'm not sure an underscore prefix is going to help.
It won't do any harm, though.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46356] [C API] Enforce usage of PyFrame_GetBack()

[Silver Jublee Gaming]

Silver Jublee Gaming  added the comment:

This must be normal

--
nosy: +silverjubleegaming

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46356] [C API] Enforce usage of PyFrame_GetBack()

[STINNER Victor]

STINNER Victor  added the comment:

It's unclear to me if the ability to read directly the PyFrameObject.f_lineno 
member is a deliberate use case, or if we should enforce the usage of 
PyFrame_GetLineNumber().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46356] [C API] Enforce usage of PyFrame_GetBack()

[STINNER Victor]

New submission from STINNER Victor :

C extensions written for Python 3.10 and older which access directly to the 
PyFrameObject.f_back member build successfully on Python 3.11, but they can 
fail because f_back must not be read directly. f_back can be NULL even if the 
frame has an outer frame.

PyFrameObject*
PyFrame_GetBack(PyFrameObject *frame)
{
assert(frame != NULL);
PyFrameObject *back = frame->f_back;
if (back == NULL && frame->f_frame->previous != NULL) {
back = _PyFrame_GetFrameObject(frame->f_frame->previous);
}
Py_XINCREF(back);
return back;
}

I suggest to remove or "hide" this member from the structure. For example, 
rename "f_back" to "_f_back" to advice developers to not access it directly.

See also bpo-46355: Document PyFrameObject and PyThreadState changes.

--
components: C API
messages: 410403
nosy: Mark.Shannon, vstinner
priority: normal
severity: normal
status: open
title: [C API] Enforce usage of PyFrame_GetBack()
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com