Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow setting cell value #74671

Closed
pitrou opened this issue May 26, 2017 · 10 comments
Closed

Allow setting cell value #74671

pitrou opened this issue May 26, 2017 · 10 comments
Assignees
@lisroach
Labels
3.7 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@pitrou
Copy link
Member

pitrou commented May 26, 2017

BPO 30486
Nosy @rhettinger, @terryjreedy, @ncoghlan, @pitrou, @vstinner, @benjaminp, @serhiy-storchaka, @lisroach, @DimitrisJim
PRs
  • bpo-30486: Allow setting cell value #1840
  • bpo-30486: Make cell_set_contents() symbol private #3668
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/lisroach'
closed_at = <Date 2017-06-08.11:45:01.119>
created_at = <Date 2017-05-26.16:17:01.425>
labels = ['interpreter-core', 'type-feature', '3.7']
title = 'Allow setting cell value'
updated_at = <Date 2017-09-20.13:54:17.955>
user = 'https://github.com/pitrou'

    bugs.python.org fields:

    activity = <Date 2017-09-20.13:54:17.955>
actor = 'vstinner'
assignee = 'lisroach'
closed = True
closed_date = <Date 2017-06-08.11:45:01.119>
closer = 'serhiy.storchaka'
components = ['Interpreter Core']
creation = <Date 2017-05-26.16:17:01.425>
creator = 'pitrou'
dependencies = []
files = []
hgrepos = []
issue_num = 30486
keywords = []
message_count = 10.0
messages = ['294554', '294573', '294577', '294583', '295057', '295058', '295416', '295417', '295476', '302617']
nosy_count = 9.0
nosy_names = ['rhettinger', 'terry.reedy', 'ncoghlan', 'pitrou', 'vstinner', 'benjamin.peterson', 'serhiy.storchaka', 'lisroach', 'Jim Fasarakis-Hilliard']
pr_nums = ['1840', '3668']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue30486'
versions = ['Python 3.7']
    @pitrou
    Copy link
    Member Author

    pitrou commented May 26, 2017

    There are use cases for setting a cell value. One such use case is for (un)pickling recursive closures (see heroic workaround here: https://github.com/cloudpipe/cloudpickle/pull/90/files#diff-d2a3618afedd4e124c532151eedbae09R74 ). Other use cases may include tinkering around and general education value.

    There also doesn't seem to be, AFAICS, any counter-indication to being able to do so. It's already possible in C using PyCell_Set(), which is a public API. It just lacks an API in Python land. For example cell_contents could become a read/write property...

    @pitrou pitrou added 3.7 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement labels May 26, 2017
    @lisroach
    Copy link
    Contributor

    This idea makes sense to me. I'll see if I can put together the code for it.

    @rhettinger
    Copy link
    Contributor

    +1 I don't see any reason this can't be writeable.

    @ncoghlan
    Copy link
    Contributor

    +1 from me, as this also has potential value in testing use cases and in dealing with some of the consequences of the zero-arg super() design (i.e. it will make the injected __class__ cell writable)

    @terryjreedy
    Copy link
    Member

    A possible counter-indication would be if setting a cell could cause a crash, as opposed to a mysterious exception. Since 3.x already allows writing any object to a cell from python code,

    def outer():
    cell = None
    def inner(ob):
    nonlocal cell
    cell = ob # rebinds <hidden-cell>.cell_contents
    return inner

    set_cell = outer()
print(set_cell.__closure__[0].cell_contents)  # None
set_cell('something')
print(set_cell.__closure__[0].cell_contents)  # 'something'

    making "cell.cell_contents = 'something'" legal should not enable more crashes.

    I think that "function.__closure__[i].cell_contents = object" is perhaps not a good idea for production code, but I think it falls within the realm of 'consenting adults code' for the other uses suggested above. How should it be documented?

    @pitrou
    Copy link
    Member Author

    pitrou commented Jun 2, 2017

    There's already a documentation change to the PR, you can leave your comments there.

    @serhiy-storchaka
    Copy link
    Member

    New changeset 64505a1 by Serhiy Storchaka (Lisa Roach) in branch 'master':
    bpo-30486: Allow setting cell value (bpo-1840)
    64505a1

    @serhiy-storchaka
    Copy link
    Member

    Thank you for your contribution Lisa!

    @lisroach
    Copy link
    Contributor

    lisroach commented Jun 9, 2017

    Thank you for you guidance, Serhiy!

    On Thu, Jun 8, 2017 at 4:45 AM, Serhiy Storchaka <report@bugs.python.org>
    wrote:

    Serhiy Storchaka added the comment:

    Thank you for your contribution Lisa!

    ----------
    resolution: -> fixed
    stage: patch review -> resolved
    status: open -> closed

    Python tracker <report@bugs.python.org>
    <http://bugs.python.org/issue30486\>

    @vstinner
    Copy link
    Member

    New changeset 0ad05c3 by Victor Stinner in branch 'master':
    bpo-30486: Make cell_set_contents() symbol private (bpo-3668)
    0ad05c3

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees

    @lisroach lisroach

    Labels
    3.7 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    7 participants
    @vstinner @ncoghlan @rhettinger @pitrou @serhiy-storchaka @lisroach @terryjreedy