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

Steven D'Aprano steve+comp.lang.python at pearwood.info
Mon Jun 17 20:41:53 EDT 2013


On Tue, 18 Jun 2013 02:26:39 +0300, Νίκος wrote:

> Στις 18/6/2013 2:09 πμ, ο/η Steven D'Aprano έγραψε:
>> {"a": "Hello world"}
>>
>> Do you see a memory location there? There is no memory location. There
>> is the name, "a", and the object it is associated with, "Hello world".
>> Either the dict, or the string, may move around memory if the
>> underlying memory manager allows it. Obviously any object in Python
>> must be *somewhere* in memory at any specific moment, but that is
>> irrelevant to understanding Python code. It is no more relevant than
>> saying that a dict {'a': 5} is just made up of bits.
> 
> Okey, the easy part was to understand how humans in high level need to
> understand namespaces and assignment (which is not copying but instead
> referencing another name to the same object).
> 
> But i would like to know, what happens internally within the python
> compiler, because obviously memory is involved.

Depends which Python compiler.

CPython, IronPython, PyPy, Jython, Nuitka, Cython, ... ? They all operate 
differently on the inside. Only the high-level Python code has to be the 
same.

Jython works according to the JRE, the Java Runtime Environment. There is 
masses of information about that on the Internet, google for it.

IronPython works according to the .Net runtime environment. Again, google 
for it.

PyPy is a VERY complex but powerful JIT compiler. You can read about it 
on the PyPy blog. Start here: http://morepypy.blogspot.com/

There's not a lot of documentation on how CPython works internally. You 
have to read the C source code. You will need to understand about garbage 
collectors, memory management, the difference between the stack and the 
heap, etc. It's a big area to study. Don't expect anyone to spend the 
days or weeks it will take to explain the whole thing.


> 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?

No. Unicode strings can be stored on disk in any encoding you like. 
Python stores string in memory as objects, which might look something 
like this:

[Type=str, size=42, data=...]

only more complicated. And subject to change -- anything you learn that 
holds for Python 3.3 might not apply for 3.2 or 3.4.

In Python 3.2 and older, the data will be either UTF-4 or UTF-8, selected 
when the Python compiler itself is compiled. In Python 3.3, the data will 
be stored in either Latin-1, UTF-4, or UTF-8, depending on the contents 
of the string.


> 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).

Good question, but I don't have a good answer. It has to do with the 
Python's memory manager, and the garbage collector. I don't know how they 
work.



> 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


Start here:

https://duckduckgo.com/html/?q=how%20computers%20work



-- 
Steven



More information about the Python-list mailing list