Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Νίκος]

On 17/6/2013 7:23 μμ, Benjamin Kaplan wrote:
> On Mon, Jun 17, 2013 at 8:55 AM, Simpleton <support at superhost.gr> wrote:
>> On 17/6/2013 5:22 μμ, Terry Reedy wrote:
>>>
>>> On 6/17/2013 7:34 AM, Simpleton wrote:
>>>>
>>>> On 17/6/2013 9:51 πμ, Steven D'Aprano wrote:
>>>>>
>>>>> Now, in languages like Python, Ruby, Java, and many others, there is no
>>>>> table of memory addresses. Instead, there is a namespace, which is an
>>>>> association between some name and some value:
>>>>>
>>>>> global namespace:
>>>>>       x --> 23
>>>>>       y --> "hello world"
>>>>
>>>>
>>>> First of all thanks for the excellent and detailed explanation Steven.
>>>>
>>>> As for namespace:
>>>>
>>>> a = 5
>>>>
>>>> 1. a is associated to some memory location
>>>> 2. the latter holds value 5
>>>
>>>
>>> This is backwards. If the interpreter puts 5 in a *permanent* 'memory
>>> location' (which is not required by the language!), then it can
>>> associate 'a' with 5 by associating it with the memory location. CPython
>>> does this, but some other computer implementations do not.
>>
>>
>> Please tell me how do i need to understand the sentence
>> 'a' is being associated with number 5 in detail.
>>
>> Why don't we access the desired value we want to, by referencing to that
>> value's memory location directly instead of using namespaces wich is an
>> indirect call?
>>
>> i feel we have 3 things here
>>
>> a , memory address of a stored value, actual stored value
>>
>>>> So is it safe to say that in Python a == &a ? (& stands for memory
>>>> address)
>>>>
>>>> is the above correct?
>>>
>>>
>>> When you interpret Python code, do you put data in locations with
>>> integer addresses?
>>
>>
>> I lost you here.
>>
>
> You're confusing the way in which the CPython interpreter is written
> with the way the Python language is defined. Yes, the CPython
> interpreter puts 5 into a numbered memory location when creating the
> object. But the Nikos Python Interpreter (which is a completely valid,
> although quite buggy, Python interpreter that uses your head to
> interpret the code) should not be using numbered memory locations.
>
> Forget about memory locations. Memory locations don't exist. Let's use
> the pen-and-paper Python interpreter. On the left side of the paper,
> we'll write down the names. On the rest of the paper, we'll write down
> the objects.
>
> When I do "x =[]", I make a new list (which means I write down []
> somewhere in the middle of the page), I create the name "x" (which
> means I write down an "x" on the left side of the page), and then I
> draw an arrow pointing from the x to the [].
> (sorry if my drawing doesn't line up in your email/news client- I'll
> try to make it line up correctly with a monospace font)
> --------------------------------------------
> |  x --------------> []                    |
> |                                          |
> |                                          |
> --------------------------------------------
>
> Now, When we do y = x, the right side of the equation is evaluated
> (which gives us the object currently bound to the name x) and it is
> then given the newly created name "y"
> --------------------------------------------
> |  x --------------> []                    |
> |                     ^                    |
> |   y ----------------|                    |
> --------------------------------------------
>
> When we do x.append(3), the object that x refers to is modified. This
> is seen by both x and y because they point to the same object.
>
> --------------------------------------------
> |  x --------------> [3]                   |
> |                     ^                    |
> |   y ----------------|                    |
> --------------------------------------------
>
> When I do x = [], a new object is created somewhere else on the page,
> and the name x is made to point to the new object. This changes the
> arrow. The name "x" is not in any way tied to the location of the [3]
> on the page. This doesn't impact "y" which is still pointing at the
> same spot it was before
>
> --------------------------------------------
> |  x -------->[]     [3]                   |
> |                     ^                    |
> |   y ----------------|                    |
> --------------------------------------------
>
> That is how Python's object model works. In CPython, objects have
> specified memory locations but names do not. In IronPython and Jython,
> even that's not guaranteed- the garbage collector can move the objects
> around during their lifetime, so while you can trust that a name will
> always point to the correct object, you have no guarantee about where
> the object is located in the computer's memory.
>
EXCELLENT EXPLANATION, THANK YOU VERY MUCH.
I AM SAVING THIS TO A .TXT FOR FUTURE REFERENCE.

THAT'S WHY I ASK YOU GUYS FOR HUMAN LIKE EXPLANATIONS.
THIS CANNOT BE FIND WITH SUCH SIMPLE WAY OF PUTTING THIS IN TECH DOCS.

Something else please:

The way some info(i.e. a Unicode string) is saved into the hdd , is the 
same way its being saved into the memory too? Same way exactly?

While you said to me to forget about memory locations, and that's indeed 
made things easy to follow i still keep wondering, how Python internally 
keeping tracks of 'x' and 'y' names as well as their referenced objects 
(i.e. number 6).

After all the way i understand memory is as a series of bits like:

0100010100011110101000010101010010001001010010011100001101001010010

So from the above binary form:

what is 'x', what is 'y', how's 'x' and 'y' differ from the actually 
memory locations that are bound too, and of course what is the actual value.

Its 3 things for me to consider, even in Python id internal level 
detail. I want to understand this.

names, memory addresses, memory address's actual values

Thanks again Benjamin for making things clear.

-- 
What is now proved was at first only imagined!