[issue31750] expose PyCell_Type in types module

[Guido van Rossum]

Guido van Rossum  added the comment:

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`.

--

___
Python tracker 

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

[issue31750] expose PyCell_Type in types module

[Devin Bayer]

Devin Bayer  added the comment:

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.

--

___
Python tracker 

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

[issue31750] expose PyCell_Type in types module

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

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.

--
nosy: +benjamin.peterson, gvanrossum

___
Python tracker 

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

[issue31750] expose PyCell_Type in types module

[Devin Bayer]

Devin Bayer  added the comment:

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])

--

___
Python tracker 

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

[issue31750] expose PyCell_Type in types module

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

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?

--
nosy: +serhiy.storchaka
versions: +Python 3.7 -Python 3.6

___
Python tracker 

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

[issue31750] expose PyCell_Type in types module

[Devin Bayer]

New submission from Devin Bayer :

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

--
components: Library (Lib)
messages: 304062
nosy: akvadrako
priority: normal
severity: normal
status: open
title: expose PyCell_Type in types module
type: enhancement
versions: Python 3.6

___
Python tracker 

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