On Sun, Jun 16, 2013 at 12:06 PM, Ferrous Cranus <supp...@superhost.gr> wrote:
I appreciate you've returned to your Ferrous Cranus persona for this
interchange. It reminds me not to get hung up on concerns of
futility...
> On 16/6/2013 1:42 μμ, R. Michael Weylandt wrote:
>>>
>>
>> ## CODE SNIPPET##
>> a = 552315251254
>> b = a
>> c = 552315251254
>>
>> a is b # True _on my machine_
>
>
> I accept this if in the premise that, b boils down to actually point to a's
> value, but it has to go through a first to find it, not directly.
You don't get to "accept it on a premise" or not. It's simply a matter of fact.
In fact, b does not go "through" a. The memory address referenced
exists even if the "a" binding is removed using "del a" or some other
mechanism. Imagine this scenario:
[a]
\
6
/
[b]
Using the name "a" or "b" simply tells Python where to look for a
value, but the value itself is not associated with "a" or "b" and will
only be removed if both a and b are del'd.
If we remove "a" while keeping "b" alive, we still have a means of
getting to "6" so Python's GC / RefCounter won't remove it. This
implies that the memory can't be solely "owned" by "a".
[a] # Binding gone now or perhaps referring to something else
6
/
[b]
And this pattern continues for any sort of Python object.
>
>> a is c # False _on my machine_
>
>
> Why false? These are 2 different memory locations storing the same number.
> This should have been True.
Again, you have the idea that you can use words like "should" here. It
either is or isn't. There's simply no normative claim involved.
>
> what id() does, never heard of that function before.
>
It seems you've also never heard of Python's "help" function?
Try
help(id)
at your interactive prompt and see what happens.
>
> --
> What is now proved was at first only imagined!
Depth of stubbornness?
--
http://mail.python.org/mailman/listinfo/python-list
