classification
Title: [C API] How many slots of static types should be exposed in PyType_GetSlot()
Type: enhancement Stage:
Components: C API Versions: Python 3.10
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: petr.viktorin, shihai1991, vstinner
Priority: normal Keywords:

Created on 2020-08-23 08:48 by shihai1991, last changed 2020-11-07 14:52 by shihai1991.

Messages (8)
msg375808 - (view) Author: hai shi (shihai1991) * (Python triager) Date: 2020-08-23 08:48
In order to resolve bpo41073, we want to extend `PyType_GetSlot()` to accept static types. But there have another question we should be considered: How many slots should be exposed in `PyType_GetSlot()`.

petr's opinion from PR-21931:I would not want to expose the Py_tp_as_* slots at all; their contents are covered in other slots that should be used instead. And slots like Py_tp_version_tag are specific to CPython; I don't think they should be exposed in the general C API.
msg375809 - (view) Author: hai shi (shihai1991) * (Python triager) Date: 2020-08-23 08:50
related bpo: bpo-41073
msg376568 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2020-09-08 12:09
IMO, a slot should be exposed if there is some reason for exposing it.

bpo-41073 talks about tp_dealloc, which is already exposed as Py_tp_dealloc.
Recently, Py_bf_* slots were exposed (but not as part of the limited API), in bpo-40724 which links to the reasons for exposing them.

Which other slots are we missing?
msg379110 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2020-10-20 09:26
Also: PyType_GetSlot should return a function pointer, not data.

For some slots (Py_tp_doc, Py_tp_methods, Py_tp_members, Py_tp_getset) that ship has sailed, but for new ones, we should honor the distinction between data and function pointers. The C standard says they're distinct, so it might bite us in the future (e.g. compiling to WebAssembly).
msg379948 - (view) Author: hai shi (shihai1991) * (Python triager) Date: 2020-10-30 11:47
> IMO, a slot should be exposed if there is some reason for exposing it.

Can we write those info to docs? In case some developer want to exposing slot in future.

> Which other slots are we missing?

nb_inserved in PyNumberMethods should be removed?
msg380303 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2020-11-03 22:26
> Can we write those info to docs? In case some developer want to exposing slot in future.

Do you mean something like "only expose a slot if you have a reason for exposing it"? That sounds like a tautology.
Where in the docs would this go?

> nb_inserved in PyNumberMethods should be removed?

You mean nb_reserved, right?
It can't be removed; old-style initialization is positional.
But it could be replaced according to PEP387:
- in 3.x, raise a warning if it is not set to NULL (in static types)
- in 3.x+2, throw an error if it is not set to NULL (in static types)
- in 3.x+3 or later, it can be replaced by another slot, if there's something we need to add to PyNumberMethods
msg380414 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2020-11-05 15:28
My views on individual slots:

Not a function, shouldn't be used with PyType_Slot:
  * tp_dict - I'd add a PyType_GetDict if there is a need to get this
  * tp_mro - I'd add a PyType_GetMRO if there is a need to get this
(There are existing slots that aren't functions; I'd like to deprecate them in the long term.)

internal use only, do not expose:
  * tp_cache
  * tp_subclasses
  * tp_weaklist
  * tp_as_*

Not part of limited API, do not expose:
  * tp_vectorcall

Can be exposed if we deem all of the related API stable:
  * bf_getbuffer
  * bf_releasebuffer
msg380510 - (view) Author: hai shi (shihai1991) * (Python triager) Date: 2020-11-07 14:52
> Do you mean something like "only expose a slot if you have a reason for > exposing it"? That sounds like a tautology.
> Where in the docs would this go?

Add a friend Note in docs of `PyType_GetSlot` MAYBE?

> You mean nb_reserved, right?
Yes, thanks for your description.
History
Date User Action Args
2020-11-07 14:52:49shihai1991setmessages: + msg380510
2020-11-05 15:28:09petr.viktorinsetmessages: + msg380414
2020-11-03 22:26:00petr.viktorinsetmessages: + msg380303
2020-10-30 11:47:36shihai1991setmessages: + msg379948
2020-10-20 09:26:32petr.viktorinsetmessages: + msg379110
2020-09-08 12:09:30petr.viktorinsetmessages: + msg376568
2020-08-23 08:50:09shihai1991setmessages: + msg375809
2020-08-23 08:48:18shihai1991create