what does 'a=b=c=[]' do

[Eric]

Is it true that if I want to create an array or arbitrary size such
as:
for a in range(n):
x.append(<some function...>)

I must do this instead?
x=[]
for a in range(n):
x.append(<some function...>)

Now to my actual question. I need to do the above for multiple arrays
(all the same, arbitrary size). So I do this:
x=y=z=[]
for a in range(n):
x.append(<some function...>)
y.append(<some other function...>)
z.append(<yet another function...>)

Except it seems that I didn't create three different arrays, I created
one array that goes by three different names (i.e. x[], y[] and z[]
all reference the same pile of numbers, no idea which pile).

This surprises me, can someone tell me why it shouldn't? I figure if
I want to create and initialize three scalars the just do "a=b=c=7",
for example, so why not extend it to arrays. Also, is there a more
pythonic way to do "x=[], y=[], z=[]"?

It's a slick language but I still have trouble wrapping my brain
around some of the concepts.

TIA,
eric

 

[Dennis Lee Bieber]

Except it seems that I didn't create three different arrays, I created
one array that goes by three different names (i.e. x[], y[] and z[]
all reference the same pile of numbers, no idea which pile).

This surprises me, can someone tell me why it shouldn't? I figure if
I want to create and initialize three scalars the just do "a=b=c=7",
for example, so why not extend it to arrays. Also, is there a more
pythonic way to do "x=[], y=[], z=[]"?

It's a slick language but I still have trouble wrapping my brain
around some of the concepts.

The key one is that lists ([] defines a list, not an array) are
"mutable". Your "7" is not mutable.

a = b = c = 7
does the same thing as
a = b = c = []
which is to define the names "a", "b", and "c", and connects the three
names to the single object (integer 7 or new empty list).

b = 8
then /disconnects/ the name "b" from the object (empty list or integer
7) and connects the name to an integer 8 object.

b = [1, 2, 3]
disconnects the name "b" from the object and connects it to a list
object containing three elements.

b.append("something")
however is going "inside" the object to change what it contains -- the
connection remains the same object however.

a,b,c=[[] for x in range(3)]
a.append(1)
b []
c []
a [1]

For the amount of typing, it's easier to just do a straight line
tuple unpack

a,b,c = ([],[],[])
a.append(2)
a [2]
b []
c []

 

[Steven D'Aprano]

Is it true that if I want to create an array or arbitrary size such as:
for a in range(n):
x.append(<some function...>)

x is not defined, so you will get a NameError unless by some lucky fluke
something else has created x AND it happens to be a list. Either way, it
is unlikely to do what you want.

I must do this instead?
x=[]
for a in range(n):
x.append(<some function...>)

Yes, you should create your lists before trying to append to them.

But you aren't forced to use a for-loop. You can use a list comprehension:

x = [some_function(a) for a in range(n)]

Notice that here you don't need x to pre-exist, because the list comp
creates a brand new list, which then gets assigned directly to x.

Now to my actual question. I need to do the above for multiple arrays
(all the same, arbitrary size). So I do this:
x=y=z=[]

This creates one empty list object, and gives it three names, x, y and z.
Every time you append to the list, all three names see the same change,
because they refer to a single list.

[...]

Except it seems that I didn't create three different arrays, I created
one array that goes by three different names (i.e. x[], y[] and z[] all
reference the same pile of numbers, no idea which pile).
Exactly.

This surprises me, can someone tell me why it shouldn't?

Because that's the way Python works. Python is an object-oriented, name
binding language. This is how OO name binding works: you have a single
object, with three names bound to it. The above line is short-cut for:

a = []
b = a
c = a

Python does not make a copy of the list unless you specifically instruct
it to.

I figure if I
want to create and initialize three scalars the just do "a=b=c=7",

That creates a single integer object with value 7, and binds three names
to it, *exactly* the same as the above.

If you could modify int objects in place, like you can modify lists in
place, you would see precisely the same effect. But ints are immutable:
all operations on ints create new ints. Lists are mutable, and can be
changed in place.

for
example, so why not extend it to arrays. Also, is there a more pythonic
way to do "x=[], y=[], z=[]"?

Well that literally won't work, you can't separate them by commas.
Newlines or semicolons will work.

Or: x, y, z = [], [], []

Either is pretty Pythonic.

 

[Steven D'Aprano]

For the amount of typing, it's easier to just do a straight line
tuple unpack

a,b,c = ([],[],[])

Note that tuples are created by the comma, not the round brackets (or
parentheses for any Americans reading). So the round brackets there are
strictly redundant:

a, b, c = [], [], []

The only times you need the brackets around a tuple is to control the
precedence of operations, or for an empty tuple.

 

[alex23]

This surprises me, can someone tell me why it shouldn't?  I figure if
I want to create and initialize three scalars the just do "a=b=c=7",
for example, so why not extend it to arrays.

The thing to remember is that everything is an object, and that it's
better to think of variables as labels on an object.

So: a=b=c=7 means that _one_ integer object with the value of 7 can be
referenced using any of the labels a, b or c. x=y=z=[] means that
_one_ empty list can be referenced using x, y or z.

The difference is that the value of a number object _cannot be
changed_ ('immutable') while a list can be modified to add or remove
items ('mutable'). a=10 just reassigns the label a to an integer
object of value 10. x.append("foo") _modifies_ the list referred to by
x, which is the same list known as y & z.

Also, is there a more pythonic way to do "x=[], y=[], z=[]"?

I'd say that _is_ the most pythonic way, it's very obvious in its
intent (or would be with appropriate names). If it bothers you that
much:

def listgen(count, default=[]):
for _ in xrange(count):
yield default[:]

x, y, z = listgen(3)

 

[Rolf Camps]

alex23 schreef op wo 21-12-2011 om 16:50 [-0800]:

This surprises me, can someone tell me why it shouldn't? I figure if
I want to create and initialize three scalars the just do "a=b=c=7",
for example, so why not extend it to arrays.

The thing to remember is that everything is an object, and that it's
better to think of variables as labels on an object.

So: a=b=c=7 means that _one_ integer object with the value of 7 can be
referenced using any of the labels a, b or c. x=y=z=[] means that
_one_ empty list can be referenced using x, y or z.

The difference is that the value of a number object _cannot be
changed_ ('immutable') while a list can be modified to add or remove
items ('mutable'). a=10 just reassigns the label a to an integer
object of value 10. x.append("foo") _modifies_ the list referred to by
x, which is the same list known as y & z.

Also, is there a more pythonic way to do "x=[], y=[], z=[]"?

I'd say that _is_ the most pythonic way, it's very obvious in its
intent (or would be with appropriate names). If it bothers you that
much:

def listgen(count, default=[]):
for _ in xrange(count):
yield default[:]

x, y, z = listgen(3)

I'm afraid it's dangerous to encourage the use of '[]' as assignment to
a parameter in a function definition. If you use the function several
times 'default' always points to the same list.

def return_list(list_ = []):
return list_
a_list = return_list()
a_list []
a_list.append(3)
a_list [3]
b_list = return_list()
b_list
[3] # !!??
def return_list():
return []
a_list = return_list()
a_list []
a_list.append(3)
a_list [3]
b_list = return_list()
b_list
[] # OK!

I only use python3 so I don't know how these things work in other
versions.

No problem in your function since you yield a copy, but I've already
seen long threads about this.

I would change your function to (Python3.x):

def empty_lists(count):
for _ in range(count):
yield []


Regards,

Rolf

 

[Ethan Furman]

alex23 schreef op wo 21-12-2011 om 16:50 [-0800]:

I'd say that _is_ the most pythonic way, it's very obvious in its
intent (or would be with appropriate names). If it bothers you that
much:

def listgen(count, default=[]):
for _ in xrange(count):
yield default[:]

x, y, z = listgen(3)

I would change your function to (Python3.x):

def empty_lists(count):
for _ in range(count):
yield []

While it's good to be careful, default mutable arguments have their
place. Alex's versioun allows one to use an already existing list and
get shallow copies of it, yours will only create empty lists.

a, b, c = listgen([1, 2, 3])
# a, b, & c are bound to different lists

~Ethan~

 

[alex23]

I'm afraid it's dangerous to encourage the use of '[]' as assignment to
a parameter in a function definition. If you use the function several
times 'default' always points to the same list.

I appreciate the concern, but adding a default argument guard would
not only obscure the code. It's irrelevant, as you recognise, because
no matter what, it's going to make copies of the default argument.

You know what the say about foolish consistencies

 

[Ian Kelly]

I'm afraid it's dangerous to encourage the use of '[]' as assignment to
a parameter in a function definition. If you use the function several
times 'default' always points to the same list.

I appreciate the concern, but adding a default argument guard would
not only obscure the code. It's irrelevant, as you recognise, because
no matter what, it's going to make copies of the default argument.

It's only irrelevant in the immediate context of the code you posted.
But when Joe Novice sees your code and likes it and duplicates it a
million times without receiving any warning about it, he's eventually
going to write a function that modifies its default list argument, and
he'll be in for a nasty surprise when he does.

 

[alex23]

It's only irrelevant in the immediate context of the code you posted.
But when Joe Novice sees your code and likes it and duplicates it a
million times

I'm sorry, but I'm not going to modify my coding style for the sake of
bad programmers.

The context is _important_. Why should I guard against default
argument mutability when its not going to occur in the function body?

 

[Eric]

This surprises me, can someone tell me why it shouldn't?  I figure if
I want to create and initialize three scalars the just do "a=b=c=7",
for example, so why not extend it to arrays.

The thing to remember is that everything is an object, and that it's
better to think of variables as labels on an object.

So: a=b=c=7 means that _one_ integer object with the value of 7 canbe
referenced using any of the labels a, b or c. x=y=z=[] means that
_one_ empty list can be referenced using x, y or z.

The difference is that the value of a number object _cannot be
changed_ ('immutable') while a list can be modified to add or remove
items ('mutable'). a=10 just reassigns the label a to an integer
object of value 10. x.append("foo") _modifies_ the list referred to by
x, which is the same list known as y & z.

Also, is there a more pythonic way to do "x=[], y=[], z=[]"?

I'd say that _is_ the most pythonic way, it's very obvious in its
intent (or would be with appropriate names). If it bothers you that
much:

Thanks for the explanation. I guess from what I've seen of Python
so far I was expecting something more, I don't know, compact.
Anyway, it doesn't bother me, at least not enough to go and do
something like this:

    def listgen(count, default=[]):
        for _ in xrange(count):
            yield default[:]

    x, y, z = listgen(3)

Thanks,
eric

 

[Chris Angelico]

I'm sorry, but I'm not going to modify my coding style for the sake of
bad programmers.

And there, folks, you have one of the eternal dilemmas. The correct
decision depends on myriad factors; if you're writing code to go into
the documentation as an example, you want it to be able to handle
idiots hacking on it - but on the other hand, that same situation
demands simplicity, which is why a lot of examples omit huge slabs of
error checking.

ChrisA

 

[Eric]

Yes, you should create your lists before trying to append to them.

But you aren't forced to use a for-loop. You can use a list comprehension:

x = [some_function(a) for a in range(n)]

Notice that here you don't need x to pre-exist, because the list comp
creates a brand new list, which then gets assigned directly to x.

Now to my actual question.  I need to do the above for multiple arrays
(all the same, arbitrary size).  So I do this:
   x=y=z=[]

This creates one empty list object, and gives it three names, x, y and z.
Every time you append to the list, all three names see the same change,
because they refer to a single list.

[...]

Except it seems that I didn't create three different arrays, I created
one array that goes by three different names (i.e. x[], y[] and z[] all
reference the same pile of numbers, no idea which pile).
Exactly.

This surprises me, can someone tell me why it shouldn't?

Because that's the way Python works. Python is an object-oriented, name
binding language. This is how OO name binding works: you have a single
object, with three names bound to it. The above line is short-cut for:

a = []
b = a
c = a

Python does not make a copy of the list unless you specifically instruct
it to.

I figure if I
want to create and initialize three scalars the just do "a=b=c=7",

That creates a single integer object with value 7, and binds three names
to it, *exactly* the same as the above.

If you could modify int objects in place, like you can modify lists in
place, you would see precisely the same effect. But ints are immutable:
all operations on ints create new ints. Lists are mutable, and can be
changed in place.

for
example, so why not extend it to arrays.  Also, is there a more pythonic
way to do "x=[], y=[], z=[]"?

Well that literally won't work, you can't separate them by commas.
Newlines or semicolons will work.

Or: x, y, z = [], [], []

Either is pretty Pythonic.

Thanks to you and Dennis for the quick lesson and tips. Very helpful
and illuminating.

 

[Ian Kelly]

I'm sorry, but I'm not going to modify my coding style for the sake of
bad programmers.

Nobody is asking you to modify your coding style. The request is that
you not throw it up as an example without mentioning the important
caveats.

Also, novice programmer == bad programmer?

 

[alex23]

Nobody is asking you to modify your coding style.  The request is that
you not throw it up as an example without mentioning the important
caveats.

No, 100% no. It's not my responsibility to mention every potentially
relevant gotcha when providing example code.

Also, novice programmer == bad programmer?

If they're wholly learning how to code by throwaway examples on
mailing lists, then yes. Object mutability is a _major_ aspect of
Python; I'm simply not going to inject an essay explaining what that
implies every time I choose to use a mutable default argument.

 

[Ethan Furman]

I'm afraid it's dangerous to encourage the use of '[]' as assignment to
a parameter in a function definition. If you use the function several
times 'default' always points to the same list.

I appreciate the concern, but adding a default argument guard would
not only obscure the code. It's irrelevant, as you recognise, because
no matter what, it's going to make copies of the default argument.

It's only irrelevant in the immediate context of the code you posted.
But when Joe Novice sees your code and likes it and duplicates it a
million times without receiving any warning about it, he's eventually
going to write a function that modifies its default list argument, and
he'll be in for a nasty surprise when he does.

And then he will learn about it and not make the mistake again (or if he
does, it take much less time to figure it out).

~Ethan~

 

[rusi]

I'm afraid it's dangerous to encourage the use of '[]' as assignment to
a parameter in a function definition. If you use the function several
times 'default' always points to the same list.

I appreciate the concern, but adding a default argument guard would
not only obscure the code. It's irrelevant, as you recognise, because
no matter what, it's going to make copies of the default argument.

You know what the say about foolish consistencies

Programming languages can have bugs as much as programs can.
A classic example is the precedence table of C which Kernighan or
Ritchie (dont remember which) admitted was wrong.

Likewise function arguments that default to mutable entities is a
known gotcha of python which is best treated as a bug in python. It
should be avoided with the suitable additional circumspection that a
language bug deserves over a program bug.

[Just my rephrasing of what Ian is saying]

 

[Ethan Furman]

I'm afraid it's dangerous to encourage the use of '[]' as assignment to
a parameter in a function definition. If you use the function several
times 'default' always points to the same list.

I appreciate the concern, but adding a default argument guard would
not only obscure the code. It's irrelevant, as you recognise, because
no matter what, it's going to make copies of the default argument.

You know what the say about foolish consistencies

Programming languages can have bugs as much as programs can.
A classic example is the precedence table of C which Kernighan or
Ritchie (dont remember which) admitted was wrong.

Likewise function arguments that default to mutable entities is a
known gotcha of python which is best treated as a bug in python. It
should be avoided with the suitable additional circumspection that a
language bug deserves over a program bug.

That is the most ridiculous thing I have heard in a while. Mutable
default arguments are *not* a bug in Python.

Reminds me of a bug report a couple years back claiming multiple
inheritence was a bug and asking it to be removed.

~Ethan~

 

[Steven D'Aprano]

Likewise function arguments that default to mutable entities is a known
gotcha of python which is best treated as a bug in python.

Nonsense. It is a feature, not a bug.

Some people might argue that it is a mistake, a minor feature which
allegedly causes more difficulties than benefits. I do not hold with that
idea. But either way, it is not a bug to be fixed, but a deliberate
consequence of intended semantics.

 

[Chris Angelico]

That is the most ridiculous thing I have heard in a while.  Mutable default
arguments are *not* a bug in Python.

Reminds me of a bug report a couple years back claiming multiple inheritence
was a bug and asking it to be removed.

Both of these could arguably be called misfeaures, but not bugs.

ChrisA