1

2 questions...

1) I am trying to wrap my brain around this... I am to understand that variables can take values using such code syntax as this:

a ,b = 2, 3

and that this would be the same as coding:

a = 2
b = 3

I hope this is correct.

So here is my puzzlement. I have the following code using a generator:

def fibonacci_generator() :

    a = b = 1

    while True :

           yield a

           a , b = b , a + b


fib = fibonacci_generator()

for i in fib :

       if i > 100 :

        break

       else : 

        print ('Generated: ', i)

print (next(fib))

(yes this is code from a python learning book)

If I were to rewrite this code and instead assign my a and b variables like so:

yield a

a = b

b = a + b

then I get different returns for a. I am not understanding why this is??? Super frustrated about it!

2) When I run the code as written the first time above, I get the number 233 printed at the end. I also cannot figure out why??!!

aIKid
  • 26,968
  • 4
  • 39
  • 65
user3113783
  • 11
  • 2

6 Answers6

2

In this code:

a, b = b, a + b

a is set to b, and b is set to a+b.

In this code:

a = b
b = a + b

a is set to b, and b is afterwards set to a+b. But since a is already set to b, then b is in fact set to b+b.

Lennart Regebro
  • 167,292
  • 41
  • 224
  • 251
1
a , b = b , a + b

is not the same as

a = b
b = a + b

Because, when you say 

a, b = b, a + b

It will first prepare the values on the right side b, a + b and assign them to the variables on the left.

thefourtheye
  • 233,700
  • 52
  • 457
  • 497
1

Python computes the right hand side first and then assigns the value (or unpacks it) on the left hand side. So, in the example:

a, b = b, a+b

compared to:

a = b
b = a + b

You have different values for a when you go to compute a + b. In the second example, when you compute a + b it is equivalent to computing b + b!

mgilson
  • 300,191
  • 65
  • 633
  • 696
1

In an assignment statement, the right-hand side is always evaluated fully before doing the actual setting of variables. Because that you get different results

levi
  • 22,001
  • 7
  • 73
  • 74
1

You are probably missing the flow of data. 

a = b     ...eqI
b = a+b    ...eqII

here, before executing b eqII, a has already stored bas a value of itself. Now when yow try execute b of eqII it comes like b=b+b. Because after executing eqI when it comes to eqII, a is bnow.

But in python you can avoid this conflict if you try a, b = b, a+b.

For your second question:
I am not sure about your code but this one will work fine in the sense of your code... 

a = b = 1
while True :

a , b = b , a + b

if a and b > 100:
    break
else: print a, b

try it !!

diffracteD
  • 758
  • 3
  • 10
  • 32
0
a, b = b, a+b

This line computes b and a+b before performing any assignment. Strictly speaking, it computes a tuple (b, a+b) and then unpacks the elements of the tuple to assign them to a and b.

a = b
b = a+b

This assigns a, then computes a+b using the new value of a.

user2357112
  • 260,549
  • 28
  • 431
  • 505
  • 2
    Actually, *strictly speaking*, no tuple is built. If you do a inspect the disassembled code (`dis.dis`), you'll notice that there is no `BUILD_TUPLE` bytecode instruction. – mgilson Dec 18 '13 at 05:41
  • @mgilson: Eh, I meant that more in terms of language semantics than implementation. It's like saying "strictly speaking, calling a function that returns an int through a `void (*)()` is undefined behavior" when really, the particular combination of compiler and settings in use results in the same series of machine instructions as if you'd used an `int (*)()`. Perhaps I should have said "semantically speaking"? It's hard to find a phrase that clearly communicates that I'm talking about what the code says Python should do, rather than the equivalent action the implementation takes. – user2357112 Dec 18 '13 at 05:50
  • @mgilson Its not **always** the case... Please check my answer and the discussion with Martijin [here](http://stackoverflow.com/a/20582989/1903116) – thefourtheye Dec 18 '13 at 06:40