This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Do not access ob_type directly, introduce Py_TP
Type: enhancement Stage: resolved
Components: Interpreter Core Versions:
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: nascheme, ronaldoussoren, serhiy.storchaka, vstinner
Priority: normal Keywords: needs review, patch

Created on 2018-09-16 12:35 by nascheme, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
py_tp_macro.txt nascheme, 2018-09-16 12:35
Pull Requests
URL Status Linked Edit
PR 9180 nascheme, 2018-09-16 12:38
Messages (4)
msg325482 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2018-09-16 12:35
My long term goal is to make it possible to make PyObject an opaque structure.  Obviously that would break nearly every 3rd party extension at this point.  However, to allow freedom on certain interpreter implementation strategies, it is helpful if code does not access ob_type, ob_refcnt and ob_size directly.  Cleaning up core Python is not too hard.

There is closed bug #26824 which proposed a similar change.  There was two main issues with that patch.  One, it causes a fair amount of code churn.  This patch does that too.  Second, replace ob->ob_type with Py_TYPE(ob) adds an extra type-cast to PyObject*.  That's not good.

In this patch, I introduce Py_TP() as a non-typecast version of Py_TYPE().  I think the name is nice as it is short and matches the struct field prefix.

This change overlaps with Victor's proposed %t or %T format code change.  The code churn is mostly caused by code that does ob->ob_type->tp_name.  I'm not against the format code idea but personally I think trying to remove borrowed references is a difficult problem and it should not hold up the relatively simple task of allowing PyObject to be opaque.

Also, I doesn't see any immediate need to make PyTypeObject opaque.  The tp_* are used everywhere and so making access macros or functions for those would be hugely disruptive.  PyTypeObject is already opaque for the limited API.  I think that's good enough for now.

If this change gets accepted, I have follow-up patches to fix access to ob_refcnt and ob_size.  Those are much smaller patches since those fields are not often accessed.
msg325517 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2018-09-17 09:30
IMHO there doesn't need to be a new API unless the semantics change w.r.t Py_TYPE (for example by adding an API that returns an owned reference instead of a borrowed reference).   Py_TYPE can work with an opaque version of PyObject by turning it into a function.

BTW. Changing PyObject into an opaque structure is non-trivial because every instance currently explicitly contains a PyObject structure as the first field of the object definition.
msg380094 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2020-10-31 20:06
This has been resolved using Py_TYPE() and Py_SET_TYPE().
msg380100 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-10-31 21:13
> This has been resolved using Py_TYPE() and Py_SET_TYPE().

Great!
History
Date User Action Args
2022-04-11 14:59:06adminsetgithub: 78885
2020-10-31 21:13:02vstinnersetmessages: + msg380100
2020-10-31 20:06:17naschemesetstatus: open -> closed
resolution: out of date
messages: + msg380094

stage: patch review -> resolved
2018-09-17 09:30:17ronaldoussorensetnosy: + ronaldoussoren
messages: + msg325517
2018-09-16 12:38:55naschemesetpull_requests: + pull_request8767
2018-09-16 12:35:22naschemecreate