Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > A certainl part of an if() structure never gets executed.

Reply
Thread Tools

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

 
 
Steven D'Aprano
Guest
Posts: n/a
 
      06-17-2013
On Mon, 17 Jun 2013 08:17:48 +0300, Νίκος wrote:

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



Let me explain how variables work in some other languages, and how they
work in Python. (And Ruby, and Java, and many others.)

In a language like Pascal, or C, the compiler keeps a table mapping
variable names to fixed memory addresses, like this:

Variable Address
======== =======
x 10234
y 10238
z 10242


Code like:

x := 42;
y := x + 1;


will get compiled into something that looks like this:

# Pseudo-code
STORE 42 AT ADDRESS 10234;
READ ADDRESS 10234;
STORE (LAST RESULT + 1) AT ADDRESS 10238;


The important thing is that memory addresses are known at compile time,
and at least in general, variables cannot move around in memory. Another
important thing is that assignment is copying:

x := y;

becomes:

READ ADDRESS 10234;
STORE (LAST RESULT) AT ADDRESS 10238;

which is equivalent to:

COPY ADDRESS 10234 TO ADDRESS 10238;

If, instead of an integer, x was an array of 1000 integers, all 1000
integers would need to be copied.

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"


In Python, namespaces are *dicts*, just like those you create with {}.

Code like:

x = 42
y = x + 1


is treated as:

# Pseudocode
create the object 42
bind it to the name 'x'
look up the name 'x'
add 1 to it
bind it to the name 'y'


where "bind" means to change the association in the namespace:

global namespace:
x --> 42
y --> 43


One important thing is that binding does *not* make a copy of the object.
Assignment is equally fast whether you have one int or a list or a
million ints. So code like this:

x = y

results in both names 'x' and 'y' being associated to the same object.
With ints, that's pretty boring, but for mutable objects like lists, it
means that you get two names for the same list:

py> x = []
py> y = x
py> y.append("Surprise!")
py> x
['Surprise!']


This sort of behaviour is trivial in languages with name-binding
semantics, like Python, but quite tricky in languages like Pascal. You
have to explicitly work with pointers or other indirect memory access,
leading to extra effort and the possibility of serious bugs.

Note also that because you aren't dealing with fixed memory addresses,
objects are free to be moved in memory for better memory usage and less
fragmentation. CPython doesn't do this, but PyPy does, and I expect that
both Jython and IronPython probably do too. So long as the runtime
environment can (somehow) track when objects are moved, it all works out
fine.

Another difference is that in C-like languages, variables always have a
value, even if it's not a useful value. As soon as the compiler decides
that variable 'z' will be at address 10242, then 'z' has an implied value
made up of whatever junk happens to be at that address. Some compilers
will warn you if you try to use a variable without assigning to it first,
since using junk you happen to find lying around in memory is usually a
bad thing, but not all compilers.

In contrast, Python doesn't have this issue. If you haven't assigned to
'z', then there is no such thing as 'z' in your namespace, and trying to
use it will automatically give you an error:

py> x = z - 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'z' is not defined


There are other differences in regards to passing arguments to functions.
I've written about that before:

http://mail.python.org/pipermail/tut...er/080505.html


--
Steven
 
Reply With Quote
 
 
 
 
Michael Weylandt
Guest
Posts: n/a
 
      06-17-2013


On Jun 17, 2013, at 6:17, Νίκος <(E-Mail Removed)> wrote:

> On 16/6/2013 9:53 μμ, R. Michael Weylandt wrote:
>> On Sun, Jun 16, 2013 at 2:47 PM, Ferrous Cranus <(E-Mail Removed)> wrote:
>>> On 16/6/2013 2:13 μμ, Jussi Piitulainen wrote:
>>>>
>>>> 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.
>>>
>>>>>> id(a) == id(b)
>>> 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.

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


I'm having trouble understanding your grammar in the above, but please re-read my note on the dual behavior of `=` here:

http://mail.python.org/pipermail/pyt...ne/649990.html

Michael

 
Reply With Quote
 
 
 
 
Simpleton
Guest
Posts: n/a
 
      06-17-2013
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

So 'a', is a reference to that memory location, so its more like a name
to that memory location, yes? Instead of accessing a memory address with
a use of an integer like "14858485995" we use 'a' instead.

So is it safe to say that in Python a == &a ? (& stands for memory address)

is the above correct?

I say this because here you said that: Instead, there is a namespace,
which is anassociation between some name and some value:

When you say that you mean that a is associated to some value as in
memory location or to that memory location's address?



--
What is now proved was at first only imagined!
 
Reply With Quote
 
Michael Torrie
Guest
Posts: n/a
 
      06-17-2013
On 06/17/2013 05:34 AM, Simpleton wrote:
> So is it safe to say that in Python a == &a ? (& stands for memory address)
>
> is the above correct?


It might be partially equivalent inside the interpreter, but it's not
something you should concern yourself with. And in general, no it's not
safe to say, since Python is a reference-counted, garbage-collected
object system and pointers in C certainly are not.

> I say this because here you said that: Instead, there is a namespace,
> which is anassociation between some name and some value:
>
> When you say that you mean that a is associated to some value as in
> memory location or to that memory location's address?


In python just think of assignment as making a name *be* an object. And
if you assign one name to another name, that makes both names be the
same object. When names are unbound (either they go out of scope or you
manually unbind them), the objects they are bound to are garbage collected.

Forget about the details of how the interpreter might doing at a low level.
 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      06-17-2013
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.

> So 'a', is a reference to that memory location, so its more like a name
> to that memory location, yes? Instead of accessing a memory address with
> a use of an integer like "14858485995" we use 'a' instead.
>
> 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?

--
Terry Jan Reedy


 
Reply With Quote
 
Simpleton
Guest
Posts: n/a
 
      06-17-2013
On 17/6/2013 2:58 μμ, Michael Torrie wrote:
> In python just think of assignment as making a name *be* an object. And
> if you assign one name to another name, that makes both names be the
> same object. When names are unbound (either they go out of scope or you
> manually unbind them), the objects they are bound to are garbage collected.


"Object" here being the memory location, right?
When we say a = 5

a = an easy way for calling that "fixed memory location" that holds our
value, instead of calling it in binary format or in hex format.
This is the direct object a is pointing too. Correct?

5 = *this* is the indirect object that a outputs when we print a.

Are the above statements correct Michael?

a = 5
b = a

a <---> memory address
b <---> memory address

I like to think a and b as references to the same memory address



--
What is now proved was at first only imagined!
 
Reply With Quote
 
Simpleton
Guest
Posts: n/a
 
      06-17-2013
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.


--
What is now proved was at first only imagined!
 
Reply With Quote
 
Benjamin Kaplan
Guest
Posts: n/a
 
      06-17-2013
On Mon, Jun 17, 2013 at 8:55 AM, Simpleton <(E-Mail Removed)> 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.
 
Reply With Quote
 
Joel Goldstick
Guest
Posts: n/a
 
      06-17-2013
On Mon, Jun 17, 2013 at 11:55 AM, Simpleton <(E-Mail Removed)> 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.
>
>
>
> --
> What is now proved was at first only imagined!
> --
> http://mail.python.org/**mailman/listinfo/python-list<http://mail.python.org/mailman/listinfo/python-list>
>



Read and study this. Then come back and ask again. Don't think of
physical representation of memory with actual binary addresses. Python is
not assembler. Neither is it C (sometimes called high level assembler)
http://docs.python.org/2/tutorial/cl...and-namespaces

--
Joel Goldstick
http://joelgoldstick.com

 
Reply With Quote
 
Νίκος
Guest
Posts: n/a
 
      06-17-2013
On 17/6/2013 7:23 μμ, Benjamin Kaplan wrote:
> On Mon, Jun 17, 2013 at 8:55 AM, Simpleton <(E-Mail Removed)> 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:

01000101000111101010000101010100100010010100100111 00001101001010010

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!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
semple code accept never executed fakessh C Programming 11 09-15-2012 05:46 AM
Using callback, I fill dorpdownlist without postback but it gets empty when a postback is executed Fabio Mastria ASP .Net 5 01-30-2008 09:07 PM
server event never/always executed phil ASP .Net Web Controls 1 06-06-2006 12:00 PM
ORIGINAL CODE GETS EXECUTED NOT THE NEW CODE - ASCX sk ASP .Net 1 04-19-2006 11:50 AM
Page_Unload gets executed twice chefo@bulgaria.com ASP .Net 0 01-21-2005 01:44 PM



Advertisments