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: expose PyCell_Type in types module
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: akvadrako, benjamin.peterson, gvanrossum, serhiy.storchaka
Priority: normal Keywords:

Created on 2017-10-10 17:46 by akvadrako, last changed 2022-04-11 14:58 by admin.

Messages (6)
msg304062 - (view) Author: Devin Bayer (akvadrako) * Date: 2017-10-10 17:46
The type of PyCell_Type is not available in the types module or anywhere else. Since this type is exposed to users it seems like it's a rather odd omission.

Related issues:
- https://bugs.python.org/issue2408
- https://bugs.python.org/issue1605
msg304063 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-10-10 17:57
According to discussions in the issues referred by you, this omission is intentional. Do you have any new arguments for adding the cell type in the types module?
msg304067 - (view) Author: Devin Bayer (akvadrako) * Date: 2017-10-10 18:47
I have just reread those discussions and I don't see any reasoning behind omitting the cell type. It is barely mentioned.

Basically, I need this type and it isn't exposed anywhere. I don't care where it is, but the only way to get it right now is a hack, for example:

a = [1]
def f(): return a
return type(f.__closure__[0])
msg304069 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-10-10 19:22
The reason is that nobody provided good enough arguments for exposing a cell type in the types module. The initial argument "types should expose all types used by the interpreter" was found to be bad. There are a lot of types (like "stderrprinter" or "list_reverseiterator") that shouldn't be exposed.
msg304074 - (view) Author: Devin Bayer (akvadrako) * Date: 2017-10-10 19:45
Well that's true enough. My main argument is consistency. Cells and code objects together make up closures, so to manipulate closures you need both. Right now I am using a ctypes hack to modify the cells/closures, for what I consider a strategically important use-case. So I guess a type(cell) hack isn't out of place; the risk is it's fragile.

So, to really make hot reloading work with no hacks I need both this and the follow-up of https://bugs.python.org/issue14369 to be implemented. Or equivalently, a python interface to make closures mutable.

Honestly I don't know what your criteria are, so it's hard to make a point.
msg304078 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2017-10-10 20:10
I think the cell type is pretty fundamental to Python's semantic model. IIRC there once was a time when cells were entirely hidden from the user, but that's no longer true. Third-party code that uses them might want to have type annotations and then it's a pain when there's no way to talk about them. And no, that doesn't mean it belongs in typing.py -- that's not a scalable model, and in general we only want to shadow things there that must be generic (but aren't in types.py), like `List` or `re.Pattern`.
History
Date User Action Args
2022-04-11 14:58:53adminsetgithub: 75931
2017-10-10 20:10:36gvanrossumsetmessages: + msg304078
2017-10-10 19:45:13akvadrakosetmessages: + msg304074
2017-10-10 19:22:16serhiy.storchakasetnosy: + gvanrossum, benjamin.peterson
messages: + msg304069
2017-10-10 18:47:22akvadrakosetmessages: + msg304067
2017-10-10 17:57:12serhiy.storchakasetnosy: + serhiy.storchaka

messages: + msg304063
versions: + Python 3.7, - Python 3.6
2017-10-10 17:46:02akvadrakocreate