On Thu, 12 Mar 2020 at 17:20, Chris Angelico <ros...@gmail.com> wrote: > > What is to stop a Python implementation (not CPython, maybe, but some > > other one) from discarding the object in x as soon as it's > > unreferenced by the (del x) expression? Then y wouldn't be able to > > hold that value. After all, in theory, after the first line our object > > has a refcount of 1, then the (del x) changes that refcount to 0, then > > y = (the value) changes it back to 1. But it could be discarded in > > that period when it has refcount 0. > > No, it wouldn't - the use of the value as a return value counts as a > reference. It's exactly the same as any other function that returns a > brand-new value.
Sorry, I my error. What I was trying to get at is that the semantics are subtle and very closely tied to precise details of how CPython's refcounting works. And I then proceeded to either undermine or prove my own argument (I can't tell which!) by misunderstanding refcount semantics myself :-) I suspect that at least part of my point stands, though - describing the semantics of the proposed "del expression" in a way that (a) can be understood independently of the CPython implementation, and (b) ensures that CPython actually implements the intended semantics of "allow the refcount-1 optimisation to apply", is likely to be extremely difficult. But I'll bow out of the discussion at this point - there's too many posts for me to keep up with it. Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PFY4MPDTEHFSIGZ3UKWG52RPDJRPBPX2/ Code of Conduct: http://python.org/psf/codeofconduct/
