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
--
http://mail.python.org/mailman/listinfo/python-list
