A certainl part of an if() structure never gets executed.

[R. Michael Weylandt]

On Sun, Jun 16, 2013 at 12:06 PM, Ferrous Cranus <support at 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?