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

[R. Michael Weylandt]

On Sun, Jun 16, 2013 at 2:38 PM, Ferrous Cranus <support at superhost.gr> wrote:
> On 16/6/2013 3:04 μμ, R. Michael Weylandt wrote:
>>>> ## CODE SNIPPET##
>>>> a = 552315251254
>>>> b = a
>>>> c =  552315251254
>>>>
>>>> a is b # True _on my machine_
>
>>
>> And this pattern continues for any sort of Python object.
>>>> a is c # False _on my machine_
>
> And in mine is also True.
>

What do you mean "also true" here? You can't be "also true" in the
presence of a false. This makes little sense to me...

>
>>>> id(a)
> 140160465571760
>>>> id(b)
> 140160465571760
>>>> id(c)
> 140160465571696
>
> Since all object result to point to actual number 6 why don't all of them
> (a,b,c) bound to the same memory address.

Look at the code they follow. (At least in this email) -- none of them
point to an object with value 6. They all point to a much larger
value.

>
> a and b seem both objects of the same identity, which means they are both
> bound to the same memory address(140160465571760)

Yes

>
> how come c's memory address is different than a's and b's ?
> After all, this is the 3rd object pointing to number 6.

Again, no it's not.

>
> And why not d and e and f and g are all objects of the same memory address?

What are these variables? They are referenced nowhere in any mail
between you and me.

>
>
a and b are the same object, with two different names. (No "if I want"
about it -- the distinction is important)

No idea what you mean by "unbounded memory address" here. (Yes I'm
aware I deleted a fairly meaningless line about it from the context)

>
> No i had no idea thagt was a bult-in help() function.
> So id() is actually the memory address of an object which uniquely
> identifies it.

Yes.


I think part of your confusion is coming from the dual interpretation
of the "=" operator in an expression like:

LHS = RHS

If RHS is some sort of literal, a conforming Python behaves as if
(modulo optimizations described below) a new object is created
according to that literal, put in memory and the name LHS is used to
point to it.

If RHS is a name (as in code such as "a = b"), the Python will find
the object to which "b" refers and add a new reference ("a") to it.

Some information on the CPython specific implementation details:

As part of the startup process, CPython creates some number of small
integers and adds them to the object cache.

Why? Because creating an object (even as simple as an int) is
relatively expensive and small integers are ubiquitous in programming.
This sacrifices some memory for a good deal of speed. But the payoff
becomes less as you go higher: almost all programs will use a 0 or a
2, fewer will use 247. At some point, the pre-creation stops. I
believe this is a compile time option.

Now, to make effective use of this caching, CPython will use a few
tricks to try to identify when one of the small ints appears in the
code. If it can identify it, I will replace the object creation with a
reference to the in-cache object. The exact times when this can happen
are not -- to my knowledge -- documented anywhere.

Now you might ask why Python doesn't realize that, in code like my
code snippet above, it could simply reuse the same int object for a,
b, and c. Conceivably it could, but it would require enormous energies
to check all currently existing objects for one that happens to be
equal to what you need (and is not mutable if that's relevant) and
it's simply faster to create the new int.

Michael