Tuple assignment and generators?

[Tim Chase]

Just as a pedantic exercise to try and understand Python a
bit better, I decided to try to make a generator or class
that would allow me to unpack an arbitrary number of
calculatible values. In this case, just zeros (though I
just to prove whatever ends up working, having a counting
generator would be nice). The target syntax would be
something like

a,b,c = zeros()
q,r,s,t,u,v = zeros()
where "zeros()" returns an appropriately sized tuple/list of
zeros.

I've tried a bit of googling, but all my attempts have just
ended up pointing to pages that blithly describe tuple
assignment, not the details of what methods are called on an
object in the process.

My first thought was to get it to use a generator:

def zeros():
while 1: yield 0

However, I get back a "ValueError : too many values to
unpack" result.

As a second attempt, I tried a couple of attempts at classes
(I started with the following example class, only derived
from "object" rather than "list", but it didn't have any
better luck):
class zeros(list): .... def __getitem__(sel f,i):
.... return 0
.... z = zeros()
a,b,c = z

Traceback (most recent call last):
File "<stdin>", line 1, in ?
ValueError: need more than 0 values to unpack
It looks like I need to have a pre-defined length, but I'm
having trouble figuring out what sorts of things need to be
overridden. It seems like I sorta need a

def __len__(self):
return INFINITY

so it doesn't choke on it. However, how to dupe the
interpreter into really believing that the object has the
desired elements is escaping me. Alternatively if there was
a "doYouHaveThisM anyElements" pseudo-function that was
called, I could lie and always return true.

Any hints on what I'm missing?

Thanks,

-tkc

[Diez B. Roggisch]

Tim Chase wrote:

Just as a pedantic exercise to try and understand Python a
bit better, I decided to try to make a generator or class
that would allow me to unpack an arbitrary number of
calculatible values. In this case, just zeros (though I
just to prove whatever ends up working, having a counting
generator would be nice). The target syntax would be
something like

<snip/>

By using this:

http://aspn.activestate.com/ASPN/Coo.../Recipe/284742
I came up with a small decorator doing that:

import inspect, dis

def expecting():
"""Return how many values the caller is expecting"""
f = inspect.current frame()
f = f.f_back.f_back
c = f.f_code
i = f.f_lasti
bytecode = c.co_code
instruction = ord(bytecode[i+3])
if instruction == dis.opmap['UNPACK_SEQUENC E']:
howmany = ord(bytecode[i+4])
return howmany
elif instruction == dis.opmap['POP_TOP']:
return 0
return 1

def variably_unpack (f):
def d(*args, **kwargs):
r = f(*args, **kwargs)
exp = expecting()
if exp < 2:
return exp
return (r.next() for i in xrange(exp))
return d

@variably_unpac k
def test():
def gen():
i = 0
while True:
yield i
i += 1
return gen()

a, b, c = test()

print a,b,c

a, b, c, d = test()

print a,b,c, d

Diez

[Larry Bates]

Tim Chase wrote:

Just as a pedantic exercise to try and understand Python a bit better, I
decided to try to make a generator or class that would allow me to
unpack an arbitrary number of calculatible values. In this case, just
zeros (though I just to prove whatever ends up working, having a
counting generator would be nice). The target syntax would be something
like

a,b,c = zeros()
q,r,s,t,u,v = zeros()
where "zeros()" returns an appropriately sized tuple/list of zeros.

I've tried a bit of googling, but all my attempts have just ended up
pointing to pages that blithly describe tuple assignment, not the
details of what methods are called on an object in the process.

My first thought was to get it to use a generator:

def zeros():
while 1: yield 0

However, I get back a "ValueError : too many values to unpack" result.

As a second attempt, I tried a couple of attempts at classes (I started
with the following example class, only derived from "object" rather than
"list", but it didn't have any better luck):
class zeros(list): ... def __getitem__(sel f,i):
... return 0
... z = zeros()
a,b,c = z

Traceback (most recent call last):
File "<stdin>", line 1, in ?
ValueError: need more than 0 values to unpack
It looks like I need to have a pre-defined length, but I'm having
trouble figuring out what sorts of things need to be overridden. It
seems like I sorta need a

def __len__(self):
return INFINITY

so it doesn't choke on it. However, how to dupe the interpreter into
really believing that the object has the desired elements is escaping
me. Alternatively if there was a "doYouHaveThisM anyElements"
pseudo-function that was called, I could lie and always return true.

Any hints on what I'm missing?

Thanks,

-tkc

While I have never needed anything like this in my 5 years of Python
programming, here is a way:

a,b,c = 3*[0]
q,r,s,t,u,v = 6*[0]

of if you like:

def zeros(num):
return num*[0]

a,b,c = zeros(3)
q,r,s,t,u,v = zeros(6)

I think the reason I don't every use anything like this is that
you don't need to initialize variables in Python to zero and I would
probably use a list instead of individual variables like q,r,s,t,u,v.

-Larry Bates

[Ant]

I don't think he was explicitly wanting to initialize things to zero,
but rather unpack an arbitrary sequence into a tuple (could perhaps be
the fibonnacci sequence for example).

How about:

def zeros(count): .... for i in range(count):
.... yield 0
.... a,b,c = zeros(3)
a 0 b 0 c

0

[Just]

In article <0K************ *************** ***@comcast.com >,
Larry Bates <la*********@we bsafe.com> wrote:

While I have never needed anything like this in my 5 years of Python
programming, here is a way:

a,b,c = 3*[0]
q,r,s,t,u,v = 6*[0]

This is (IMO) fairly idiomatic:

a = b = c = 0
q = r = s = t = u = v = 0

Just

[Larry Bates]

Just wrote:

In article <0K************ *************** ***@comcast.com >,
Larry Bates <la*********@we bsafe.com> wrote:

While I have never needed anything like this in my 5 years of Python
programming, here is a way:

a,b,c = 3*[0]
q,r,s,t,u,v = 6*[0]

This is (IMO) fairly idiomatic:

a = b = c = 0
q = r = s = t = u = v = 0

Just

You must be careful with this as they all point to
exactly the same object. Example:

q = r = s = t = u = v = 0
id(q) 3301924 id(r) 3301924 id(s) 3301924
Notice that all of them point to exactly the same object,
not 6 copies of zero which is "probably" what the poster
was thinking.

Most of the time when I see this, it is because people are
thinking of variables having values which is mostly a
carry-over from old Fortran/Cobol/Basic programming ideas.
In python variables are pointers to objects. Objects could
be values, but they are not placeholders where you store
stuff.

I read on this list (quite frequently) that people
think they are getting 6 separate variables each with
a zero stored in them. They are not. They are getting
six pointers that all point to an integer zero (IMHO it
would be a rather odd application for a programmer
to want this). Here is where multiple assignments
causes problems for beginners:
a=[]
b=c=a
a.append(6)
b

[6]

What?? 'b' should contain an empty list, right? Nope.
a, b, and c all point to the SAME list just like the
poster's q, r, s, t, u, v all point to the SAME zero.

What they meant to write was:

c=a[:] # Shallow copy of list
b=a[:]

My rule, don't do it unless you know exactly why you
want to do it. It will trip you up at some point and
be VERY hard to find.

-Larry Bates

[Tim Chase]

> I don't think he was explicitly wanting to initialize

things to zero, but rather unpack an arbitrary sequence
into a tuple (could perhaps be the fibonnacci sequence
for example).
Ant is correct here...Fibonnac i, digits of pi, the constant
42, an incrementing counter, a series of squares, whatever.
That was my original intent in the matter. Zeros just
happened to be a nice sort of place to start my exercise.
How about:

def zeros(count):
... for i in range(count):
... yield 0

One of the things I was trying to avoid was having to know
(and maintain) the count of items initialized. In the
theoretical world of my example, one could do something like

def counter():
counter = 0
while 1:
yield counter
counter += 1

and then initialize several variables, such as

a,b,c,d,e,f,g = counter()
a,b,c,d,e,f,g

(0,1,2,3,4,5,6)

It's similar to C's auto-numbering of enum values...If I
want to add another entry to a C enum, I just put it there,
and let the language take care of matters. With most of the
provided solutions, I also have to increment the count each
time I add an item to the list.

Diez provided an elegant solution with a decorator
(employing an incredibly ugly sort of hack involving
sniffing the opcode stack behind the scenes) that does what
I was looking for.

I was hoping that there was just some __foo__ property I was
missing that would have been called in the process of tuple
unpacking that would allow for a more elegant solution such
as a generator (or generator method on some object) rather
than stooping to disassembling opcodes. :)

Ah well.

-tkc

[jemfinch]

Larry Bates wrote:

Just wrote:

In article <0K************ *************** ***@comcast.com >,
Larry Bates <la*********@we bsafe.com> wrote:

While I have never needed anything like this in my 5 years of Python
programming, here is a way:

a,b,c = 3*[0]
q,r,s,t,u,v = 6*[0]
This is (IMO) fairly idiomatic:

a = b = c = 0
q = r = s = t = u = v = 0

Just

You must be careful with this as they all point to
exactly the same object. Example:

q = r = s = t = u = v = 0
id(q) 3301924 id(r) 3301924 id(s) 3301924
Notice that all of them point to exactly the same object,
not 6 copies of zero which is "probably" what the poster
was thinking.

Numbers are immutable. They're never copied. Zero, in particular, is
the same variable all throughout a Python interpreter.
Most of the time when I see this, it is because people are
thinking of variables having values which is mostly a
carry-over from old Fortran/Cobol/Basic programming ideas.
Most of the time when I see it, it's written by someone who's used
Python for quite some time. It's a standard Python idiom. You'll find
it all over the standard library. It's not a carry-over from
Fortran/Cobol/Basic at all.
In python variables are pointers to objects. Objects could
be values, but they are not placeholders where you store
stuff.
And all immutable objects are indistinguishab le from values. Immutable
objects include ints, longs, strings, unicode objects, tuples,
frozensets, and perhaps some others that I'm forgetting.
I read on this list (quite frequently) that people
think they are getting 6 separate variables each with
a zero stored in them.
That's because they are. They're getting 6 different pointers
(bindings) to zero. If you change one, the others remain pointed at
(bound to) zero.
They are not. They are getting
six pointers that all point to an integer zero
Six *different* pointers. Six *different* bindings.
(IMHO it
would be a rather odd application for a programmer
to want this).
No, it wouldn't be. It's exactly how a person works with immutable
(value) objects.
Here is where multiple assignments
causes problems for beginners:
a=[]
b=c=a
a.append(6)
b

[6]

Yes, that does sometimes trouble beginners to programming. But so do
regular expressions. Programmers ought not to restrict themselves by
what beginners will have no difficulty learning.
What?? 'b' should contain an empty list, right? Nope.
a, b, and c all point to the SAME list just like the
poster's q, r, s, t, u, v all point to the SAME zero.
There is only one zero in Python! It can never change!
What they meant to write was:

c=a[:] # Shallow copy of list
b=a[:]

My rule, don't do it unless you know exactly why you
want to do it. It will trip you up at some point and
be VERY hard to find.

Your rule should only be followed by people who obstinately refuse
either to understand the way variable bindings work in Python, or by
people who refuse to know or care whether a given kind of object is
immutable. And that group of people doesn't seem to include any of the
good Python programmers I know.

Jeremy

[jemfinch]

> Zero, in particular, is the same variable all throughout a Python interpreter.

For the sake of accuracy let me note that I ought to have said, "is the
same *value* all throughout a Python interpreter."

Jeremy

[Ben Finney]

je******@gmail. com writes:

There is only one zero in Python! It can never change!

+0.5 QOTW

--
\ "Madness is rare in individuals, but in groups, parties, |
`\ nations and ages it is the rule." -- Friedrich Nietzsche |
_o__) |
Ben Finney