Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: MRAB <python@mrabarnett.plus.com>
Newsgroups: comp.lang.python
Subject: Re: What is a function parameter =[] for?
Date: Fri, 27 Nov 2015 02:56:12 +0000
Lines: 69
Message-ID: <mailman.162.1448592976.20593.python-list@python.org>
References: <mailman.33.1448398558.20593.python-list@python.org> <n32jqq$k4j$1@dont-email.me> <mailman.35.1448400323.20593.python-list@python.org> <56550273$0$1585$c3e8da3$5496439d@news.astraweb.com> <mailman.64.1448445391.20593.python-list@python.org> <5655f27b$0$1614$c3e8da3$5496439d@news.astraweb.com> <w2dh9k9bjhq.fsf@daphne.csail.mit.edu> <mailman.109.1448504727.20593.python-list@python.org> <w2dd1uxbd1c.fsf@daphne.csail.mit.edu> <6imd5b9it55sucrcl95o95tppro7errfsi@4ax.com> <5657b30d$0$1600$c3e8da3$5496439d@news.astraweb.com> <mailman.160.1448588423.20593.python-list@python.org> <5657c376$0$1618$c3e8da3$5496439d@news.astraweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
In-Reply-To: <5657c376$0$1618$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Xref: csiph.com comp.lang.python:99622

On 2015-11-27 02:44, Steven D'Aprano wrote:
> On Fri, 27 Nov 2015 12:40 pm, Ben Finney wrote:
>
>> Steven D'Aprano <steve@pearwood.info> writes:
>>
>>> On Thu, 26 Nov 2015 09:34 pm, Dave Farrance wrote:
>>>
>>>
>>> > (Conversely, I see that unlike CPython, all PyPy's numbers have
>>> > unchanging ids, even after exiting PyPy and restarting, so it seems
>>> > that PyPy's numerical ids are "faked".)
>>>
>>> I'm pretty sure that they are faked.
>>
>> It's still not been expressed what “fake” refers to here. Or, rather,
>> what “real” thing was being expected, and how these don't qualify.
>
> They are faked in the sense that in this implementation, the object lifespan
> that you think of as the Python programmer has little if any connection to
> the actual lifespan of the chunk of memory representing that object.
>
> Suppose you have a Python object which in turn contains three other objects:
>
> L = [10001, 10002, 10003]
>
> Take the id of that list:
>
> myid = id(L)
>
> You do some long-running processing of that list, and then compare the id at
> the end:
>
> assert myid == id(L)
>
> This is guaranteed to pass by the language definition.
>
> We can say that at *every instant* from the creation of the list to the
> moment it is garbage collected, if you took a snap-shot of the process'
> memory, and manually scanned through it, you could be able to identify four
> object structs, corresponding to the list and the three ints. They might
> move around and be found in different memory locations, (as in IronPython
> and Jython), but they will be there.
>
> But not with PyPy. Not only might the objects have moved location, but in
> some snapshots you won't find them at all. The JIT compiler may convert the
> high-level Python objects (a list, and three ints) to (let's say) a
> low-level array containing three C shorts, perform processing on that, and
> then recreate the Python objects only when finished.
>
> Looked at from the perspective of the implementation, the actual lifespan of
> the objects (in the sense of the struct in memory that represents that
> object) may be much less than what we see from the perspective of the
> high-level Python code.
>
> Of course in Python, the object continues to exist the whole time, as far as
> we can tell -- there is no test we can do from Python code that can
> distinguish the state of the object, just as there is no test we can do
> from Python to tell whether an object has moved memory location or not. But
> from outside of Python -- say, a debugger that hooks into the particular
> implementation, or by taking a dump of the memory and looking at it in a
> hex editor -- we can see the high-level objects come and go and move
> around.
>
> The PyPy implementation has to take special actions to preserve the ID
> across object recreations. That is what I mean by "faked".
>
You could argue that it _does_ continue to exist, it just changes its 
form...