[issue34704] Do not access ob_type directly, introduce Py_TP

[STINNER Victor]

STINNER Victor  added the comment:

> This has been resolved using Py_TYPE() and Py_SET_TYPE().

Great!

--

___
Python tracker 

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

[issue34704] Do not access ob_type directly, introduce Py_TP

[Neil Schemenauer]

Neil Schemenauer  added the comment:

This has been resolved using Py_TYPE() and Py_SET_TYPE().

--
resolution:  -> out of date
stage: patch review -> 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

[issue34704] Do not access ob_type directly, introduce Py_TP

[Ronald Oussoren]

Ronald Oussoren  added the comment:

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.

--
nosy: +ronaldoussoren

___
Python tracker 

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

[issue34704] Do not access ob_type directly, introduce Py_TP

[Neil Schemenauer]

Change by Neil Schemenauer :


--
pull_requests: +8767

___
Python tracker 

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

[issue34704] Do not access ob_type directly, introduce Py_TP

[Neil Schemenauer]

New submission from Neil Schemenauer :

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.

--
components: Interpreter Core
files: py_tp_macro.txt
keywords: needs review, patch
messages: 325482
nosy: nascheme, serhiy.storchaka, vstinner
priority: normal
severity: normal
stage: patch review
status: open
title: Do not access ob_type directly, introduce Py_TP
type: enhancement
Added file: https://bugs.python.org/file47806/py_tp_macro.txt

___
Python tracker 

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