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

[Ferrous Cranus]

Actually, y'all both might be. This is a bit CPython specific and not
mandated by the language specification.

To Nikos: please don't extrapolate from the examples below. They are a
CPython (the most common implementation of the Python language)
specific detail.

## CODE SNIPPET##
a = 6; b = a; c = 6

id(a)
id(b)
id(c)
## END CODE##

These are all the same, indicating that they all point to the "same 6"
in memory. That's a CPython specific optimization (caching small
integers) which is not guaranteed by the language and changes between
pythons and between compiles.

For example,

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

a is c # False _on my machine_

Why false? These are 2 different memory locations storing the same number.
This should have been True.

Looks very weird.

a = memory location storing a value
b = memory location storing a's memory location
c = memory location storing a value, the same value as a

id(a)
id(b)
id(c)
## END CODE##

Note that to compare if two names point to the same "object, you can
use the "is" operator.

a is b
c is a

etc.

what id() does, never heard of that function before.

 

[Jussi Piitulainen]

I believe you are mistaken.

a here is not a pointer but variable,
which is a memory location that stores value 6.

b here is a pointer. It's value is the memory location of variable a
which stores value 6.

c here is just te same as a , a variable.

b is also just like a.

All the talk about pointers and memory locations is intended to
explain how things do or do not change. (Or, sometimes, how the
behaviour is implemented.)

If, instead of the above, you have

a = 6
b = a
b = 5

you will find that b == 5 and a == 6. So b is not the same as a. Else
one would have changed when the other changed. I would say that a and
b are different variables. They had the same value, briefly.

What does same mean? Think of mutable objects. A dictionary, for
example:

a = dict(x = 3)
b = a
b.update(x = 31)

You will find that the value of a changed when the value of b changed.
It's the same value. Values do not get copied in Python when you pass
them around. This is implemented with pointers and memory locations,
but in Python these implementation details are normally hidden behind
the scenes.

Python is far from unique in this regard.

 

[Andreas Perstinger]

C:

int a, b;
b = 6;
a = b;

In C, this places the numeric value 6 into the memory location identified
by the variable "b",

so far so good.

then copies the value from the location pointed to by "b" into the
location pointed to by "a".

Wrong. Neither "a" nor "b" are pointers, thus they don't point to a
memory location.
This part should be written as
"then copies the value at the location identified by "b" to the location
identified by "a".

b is a pointer to a memory location containing the value 6
a is a pointer to another memory location also containing the value 6

Again, neither "a" nor "b" are pointers.
"b" is the name of a memory location containing the integer value 6.
"a" is the name of another memory location containing the integer value 6.

Python:

b = 6
a = b

In Python, this first puts the value 6 in in a memory location and points
"b" at that memory location, then makes "a" point to the same memory
location as "b" points to.

b is a pointer to a memory location containing the value 6
a is a pointer to the same memory location

I wouldn't use the term "pointer" in context with Python. Using the
terms from the language reference I would write that as
"In Python, this first creates an integer object with value 6 and then
binds the name "b" to it. Then it binds the name "a" to the same object.
Thus both "a" and "b" reference the same object, i.e. they are different
names for the same object."

Bye, Andreas

 

[Mark Lawrence]

what id() does, never heard of that function before.

what google does, never heard of that function before.

--
"Steve is going for the pink ball - and for those of you who are
watching in black and white, the pink is next to the green." Snooker
commentator 'Whispering' Ted Lowe.

Mark Lawrence

 

[YBM]

Le 16.06.2013 13:06, Ferrous Cranus a écrit :

what id() does, never heard of that function before.

just type help(id) at Python prompt and stop flooding the group with
superfluous demands.

 

[R. Michael Weylandt]

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

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
/


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
/


And this pattern continues for any sort of Python object.

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.

Depth of stubbornness?

 

[Steven D'Aprano]

OK, I give up!

Actually, that's a more subtle question than most people think. Python,
for example, is a compiled language. (What did you think the "c" in
".pyc" files stood for? and the compile() function>?) It is compiled to
byte-code, which runs on a virtual machine, rather than machine-code,
which runs on a physical machine. Except PyPy, which *is* compiled to
machine-code. Except that it doesn't do so at compile time, but on the
fly at run-time.

And these days, for many types of hardware, even machine-code is often
interpreted by a virtual machine on a chip. And even languages which
compile to machine-code often use an intermediate platform-independent
form rather than targeting pure machine-code. The line between compilers
and interpreters is quite fuzzy.

Probably the best definition I've seen for the difference between a
modern compiler and interpreter is this one:

"...the distinguishing feature of interpreted languages is not that they
are not compiled, but that the compiler is part of the language runtime
and that, therefore, it is possible (and easy) to execute code generated
on the fly."
-- Roberto Ierusalimschy, "Programming In Lua", 2nd Edition, p. 63

 

[Steven D'Aprano]

That may be true in some sense for CPython, the reference implementation,
but it is not a promise of the language. For example, in PyPy objects are
free to move around in memory, so you cannot meaningfully speak of
"putting 6 in a memory location" or having a variable "point to the same
memory location".

The language promise is that the two names, "a" and "b", both refer to
the same object. In the same way that, depending on who you ask, "Barack
Obama", "Mr President", and "Dad" are three names referring to the same
person. Anything more than that depends on the implementation.


[...]

For example, in Python

a = 6
b = a
c = 6

a and b point to one memory location that contains the value 6 c points
to a different memory location that contains the value 6

Well, maybe it does, maybe it doesn't. This is one area where the
language does not specify the underlying behaviour. Because ints are
unchangeable, immutable objects, the implementation is free to cache and
reuse them if it wants. CPython caches small integers, but not floats.
Other implementations may cache fewer, or more, immutable objects.

One thing which no Python implementation can do though is re-use
*mutable* objects.


[...]

These are really C terms, not Python terms. Stop thinking that C is
behaving like Python.

This is certainly true!

 

[Dave Angel]

so far so good.


Wrong. Neither "a" nor "b" are pointers, thus they don't point to a
memory location.
This part should be written as
"then copies the value at the location identified by "b" to the location
identified by "a".

But it doesn't. It binds b to the same object to which a is currently
bound.

Again, neither "a" nor "b" are pointers.
"b" is the name of a memory location containing the integer value 6.
"a" is the name of another memory location containing the integer value 6.

Not even close. If you don't like the terms "bound" or "points", the
perhaps you'd be happy with "b" is the name that currently knows how to
find an int object containing 6. That object has no name, and never
will. And it can exist for a long time with no names directly bound to it.

I wouldn't use the term "pointer" in context with Python. Using the
terms from the language reference I would write that as
"In Python, this first creates an integer object with value 6 and then
binds the name "b" to it. Then it binds the name "a" to the same object.
Thus both "a" and "b" reference the same object, i.e. they are different
names for the same object."

Bye, Andreas

Doing all of this discussion with immutable objects masks the real
behavior, as someone can use a false model and seem to justify that
model. I don't think you're doing that, but others in the thread are.

 

[Ferrous Cranus]

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


And this pattern continues for any sort of Python object.

And in mine is also True.

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.

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

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.

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

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
/


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

If i understood you correctly, you say:

unbounded memory address = value of 6

a = pointer to memory address that holds 6
b = pointer to memory address that holds 6

So, a and b, are two objects(two variable names if you want) that are
bounded to the same memory address. And their value is the address of
unbounded memory address.
Correct?

It seems you've also never heard of Python's "help" function?

Try

help(id)

at your interactive prompt and see what happens.

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.

 

[Ferrous Cranus]

If, instead of the above, you have

a = 6
b = a
b = 5

you will find that b == 5 and a == 6. So b is not the same as a. Else
one would have changed when the other changed. I would say that a and
b are different variables. They had the same value, briefly.

If they were different variables then they would have different memory
addresses and they would act like two different objects.

But... both a and b are for a fact mappings for the same memory address
as seen form the following command.
True

They are like the same object with 2 different names.
Like i'am a human being and me Greek friends call me "Îίκος" while you
guys call me "Nick".

That the way i understand it so far.

 

[Andreas Perstinger]

^^^^^^^^^
^^^^^^^^^^^^^


But it doesn't. It binds b to the same object to which a is currently
bound.

Are you aware that Denis was talking about the behaviour of C in the
above quote?

Not even close. If you don't like the terms "bound" or "points", the
perhaps you'd be happy with "b" is the name that currently knows how to
find an int object containing 6. That object has no name, and never
will. And it can exist for a long time with no names directly bound to it.

Again, Denis was talking about C.

Bye, Andreas

 

[R. Michael Weylandt]

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

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

 

[R. Michael Weylandt]

If they were different variables then they would have different memory
addresses and they would act like two different objects.

But... both a and b are for a fact mappings for the same memory address as
seen form the following command.

True

They are like the same object with 2 different names.

This will depend on when the test is run:

a = 6
b = a
a is b # True

b = 5
a is b # False

The latter is false because the binding of "b" to the int 6 was broken
in order to bind b to the int 5.

I might also suggest you restrain from trying to correct respondents
on these matters until you yourself understand them. It's only polite.

Michael

 

[Mark Janssen]

Whats the difference of "interpreting " to "compiling" ?

Actually, that's a more subtle question than most people think. Python,
for example, is a compiled language. (What did you think the "c" in
".pyc" files stood for? and the compile() function>?)

Careful there. This terminology is not agreed upon universally (that
is, within the realm of academia where the notion of mastery exists),
and unless you are citing an actual reference or publishing one
yourself, then you may be adding more confusion than illumination.
For example, I would say that it is an *interpreted language* that
gets compiled at run-time. Some (*valid*) definitions of "compiler"
mean a strict mapping from the language syntax and lexical definition
to a sequence of bytes that can be fed to a (hardware not virtual)
machine architecture to do perform what is requested. The face that
an extension ends in the letter "c" is not sufficient evidence, since
file extensions have no strict standard.

And these days, for many types of hardware, even machine-code is often
interpreted by a virtual machine on a chip. And even languages which
compile to machine-code often use an intermediate platform-independent
form rather than targeting pure machine-code.

Do you have a reference for this? What language?

The line between compilers
and interpreters is quite fuzzy.

It shouldn't be. What is fuzzy is the definition of "interpreter",
however. The definition of compiler has only become fuzzy with the
advent of the personal computer.

Probably the best definition I've seen for the difference between a
modern compiler and interpreter is this one:

"...the distinguishing feature of interpreted languages is not that they
are not compiled, but that the compiler is part of the language runtime
and that, therefore, it is possible (and easy) to execute code generated
on the fly."

That's reasonable.

 

[Steven D'Aprano]

Careful there. This terminology is not agreed upon universally

Which is why I said it was a more subtle question than most people think.
Most people think that there is One True Definition of compiling/
interpreting, usually based on an over-simplified model of program
execution that was obsolete in the 1970s.

(that
is, within the realm of academia where the notion of mastery exists),

The notion of mastery exists in many places, not just academia.

and unless you are citing an actual reference or publishing one
yourself, then you may be adding more confusion than illumination. For
example, I would say that it is an *interpreted language* that gets
compiled at run-time.

Apart from the contradiction there -- if it is compiled, why do you
insist on calling it interpreted? -- you would be wrong. Languages are
neither interpreted nor compiled. Languages are abstract entities that
describe what syntax is permitted, and what functionality is provided. It
is only concrete implementations which are interpreted or compiled.

In the case of Python, we have:

CPython: compiled to byte-code for it's own virtual machine;

Jython: compiled to byte-code for the JRE;

IronPython: compiled to byte-code for the .Net runtime;

PyPy: JIT compiler that generates machine code;

Nuitka: static compiler that generates machine code;

etc. So, the answer to the question "Is Python compiled or interpreted?"
is, "Yes."



[...]

Do you have a reference for this? What language?
https://en.wikipedia.org/wiki/Microcode




It shouldn't be.

Of course it should be, because that reflects reality.

What is fuzzy is the definition of "interpreter",
however. The definition of compiler has only become fuzzy with the
advent of the personal computer.

Incorrect. Lisp predates the PC, and it is a good example of a language
with implementations which combine features of compile-to-machine-code
and execute-high-level-code-at-run-time (i.e. both "compiler" and
"interpreter" behaviour, at the same time). Lisp is nearly as old as
Fortran.

Forth is another such language. It's not quite so old as Lisp, but it is
especially interesting because Forth includes commands to switch from
"compile mode" to "interpret mode" on the fly. So is it a compiler or an
interpreter? Yes.

 

[Chris Angelico]

Of course it should be, because that reflects reality.

It's fuzzy AND it seldom even matters. Compare these three text strings:

"""'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'""""

"""'a'*64"""

"""\37\213\b\b*8\276Q\0\3test\0KL\244\f\0\0Ue\264\211@\0\0\0"""

"""\x78\xda\x4b\x4c\xa4\x0c\0\0\x14\x8d\x18\x41"""

Which of these is an interpreted program? I would say: All of them.
And they all produce the same output, a series of 64 copies of the
letter a. The third one is interpreted by gzip(1) and will create a
file called 'test', the fourth is a raw gzip/zlib stream and so is
interpreted by (eg) the Python zlib.decompress() function. They're all
languages, of a sort. Are they interpreted/compiled versions of that
message? Kinda. If you prepend a sfx header to them, do they become
compiled and not interpreted? Doubtful. I don't think you could say
that this ceases to be interpreted:

import zlib
print(zlib.decompress(
"""\x78\xda\x4b\x4c\xa4\x0c\0\0\x14\x8d\x18\x41"""
))

Even if you manually imported the code for zlib.decompress, in a way
that makes it impossible for your cut-down program to actually
compress data (which then breaks the principle quoted from
"Programming in Lua"), it's still fairly clearly being
interpreted/parsed the exact same way.

So it really doesn't matter (so it really doesn't matter (so it really
doesn't matter)). [1]

ChrisA

[1] http://math.boisestate.edu/gas/ruddigore/web_opera/rudd24.html

 

[Dave Angel]

Are you aware that Denis was talking about the behaviour of C in the
above quote?

Nope, missed that. Sorry for the noise.

 

[Dennis Lee Bieber]

Careful there. This terminology is not agreed upon universally (that
is, within the realm of academia where the notion of mastery exists),
and unless you are citing an actual reference or publishing one
yourself, then you may be adding more confusion than illumination.
For example, I would say that it is an *interpreted language* that
gets compiled at run-time. Some (*valid*) definitions of "compiler"
mean a strict mapping from the language syntax and lexical definition
to a sequence of bytes that can be fed to a (hardware not virtual)
machine architecture to do perform what is requested. The face that
an extension ends in the letter "c" is not sufficient evidence, since
file extensions have no strict standard.

And I'd tend to consider it a Byte-Code Interpreted language (a la UCSD
P-code Pascal). I also consider standard Java to be such.

In contrast, I consider "compiled" to mean the end result of the
compilation step is native instruction set for the processor. And true
"interpreted" is more like classic BASIC (which /tokenized/ the program but
the tokens mapped 1:1 with the source keywords. Tokenization saved a few
bytes as "while" and "for" condensed to single bytes -- but then needed
long subroutines at run time to actually process them.

 

[Íßêïò]

This will depend on when the test is run:

a = 6
b = a
a is b # True

b = 5
a is b # False

The latter is false because the binding of "b" to the int 6 was broken
in order to bind b to the int 5.

Very surprising.
a and b was *references* to the same memory address, it was like a
memory address having 2 names to be addresses as.

b = a name we use to address some memory location, do we agree on that?

So, b = 6, must have changed the stored value of its mapped memory
location, but given you example it seems its changing the mapping of b
to some other memory address.

I don't follow its act of course.