470,616 Members | 2,296 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,616 developers. It's quick & easy.

Semantics of the empty list

I fully understand why this happens:

----------------------------
a = [[], [], [], [], []]
b = [[]] * 5
a [[], [], [], [], []] b [[], [], [], [], []] a == b True id(a[0]) == id(a[1]) False id(b[0]) == id(b[1]) True a[1].append(42)
a [[], [42], [], [], []] b[1].append(42)
b [[42], [42], [42], [42], [42]]
----------------------------

What is curious to me is the implication that there are multiple,
distinct empty list objects (whose ids are not equal). Is this the case
for all mutable objects?

I wonder if it would be useful to have some symbol whose semantics are
"distinct mutable." For the sake of discussion, let's say the symbol \\
means the same as [] (i.e. it's the empty list), but with this "distinct
mutable" semantic. Then I could safely do something like:
b = [\\] * 5
b [[], [], [], [], []] id(b[0]) == id(b[1]) False

to safely initialize b as a list of distinct empty lists. As it is now,
I have to do something like this:
b = [[] for x in range(5)]


in order to get the semantic I want. It's not any great hardship, of
course, but I have been bitten by the [[]] * 5 case and its cousins on
several occasions, and it might be nice if there were a separate
semantic as described above to make it more clear what's going on.

Just some random thoughts...

Dave
Jul 18 '05 #1
3 1501
Dave,

I agree that it is HIGHLY unlikely that if a
programmer types:

b=[[]]*5

what they wanted is to create a list with 5 instances
of the same empty list, but I don't have a suggestion
for an "alternative" grammar. It's almost like this
"shortcut" shouldn't work at all because it will almost
always create something you didn't want. Then you would
HAVE to use loop/append or list comprehension method
that work as expected.

Larry Bates
Syscon, Inc.

"Dave Opstad" <da*********@agfamonotype.com> wrote in message
news:da*******************************@reader0903. news.uu.net...
I fully understand why this happens:

----------------------------
a = [[], [], [], [], []]
b = [[]] * 5
a [[], [], [], [], []] b [[], [], [], [], []] a == b True id(a[0]) == id(a[1]) False id(b[0]) == id(b[1]) True a[1].append(42)
a [[], [42], [], [], []] b[1].append(42)
b [[42], [42], [42], [42], [42]]
----------------------------

What is curious to me is the implication that there are multiple,
distinct empty list objects (whose ids are not equal). Is this the case
for all mutable objects?

I wonder if it would be useful to have some symbol whose semantics are
"distinct mutable." For the sake of discussion, let's say the symbol \\
means the same as [] (i.e. it's the empty list), but with this "distinct
mutable" semantic. Then I could safely do something like:
b = [\\] * 5
b [[], [], [], [], []] id(b[0]) == id(b[1]) False

to safely initialize b as a list of distinct empty lists. As it is now,
I have to do something like this:
b = [[] for x in range(5)]


in order to get the semantic I want. It's not any great hardship, of
course, but I have been bitten by the [[]] * 5 case and its cousins on
several occasions, and it might be nice if there were a separate
semantic as described above to make it more clear what's going on.

Just some random thoughts...

Dave

Jul 18 '05 #2
Dave Opstad <da*********@agfamonotype.com> wrote:

What is curious to me is the implication that there are multiple,
distinct empty list objects (whose ids are not equal). Is this the case
for all mutable objects?


Any list, string, tuple, or dictionary can be empty. The fact that a list
is "empty" does not automatically turn it into "THE empty list object".

Your first example creates 5 new objects, each of which becomes an empty
list, and stores a reference to each in the outer list. Your second
example creates 1 new object, and stores 5 references to it in the outer
list.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Jul 18 '05 #3
Dave Opstad <da*********@agfamonotype.com> writes:
I fully understand why this happens:

----------------------------
a = [[], [], [], [], []]
b = [[]] * 5
a [[], [], [], [], []] b [[], [], [], [], []] a == b True id(a[0]) == id(a[1]) False id(b[0]) == id(b[1]) True a[1].append(42)
a [[], [42], [], [], []] b[1].append(42)
b [[42], [42], [42], [42], [42]]
----------------------------

What is curious to me is the implication that there are multiple,
distinct empty list objects (whose ids are not equal).
Where is this implication ?
I wonder if it would be useful to have some symbol whose semantics are
"distinct mutable."
Distinct from _what_ ?

You'd have to include the memory address of each object in its printed
representation ... which would make it unreadable (unless you want to
make it really evil).

For the sake of discussion, let's say the symbol \\
means the same as [] (i.e. it's the empty list), but with this "distinct
mutable" semantic. Then I could safely do something like:
b = [\\] * 5
b [[], [], [], [], []]


How do I know, from this printed representation, whether the ids of
the elements are the same ?

Besides, you are now, implicitly, overriding the behaviour of
list.__mul__.
id(b[0]) == id(b[1]) False

to safely initialize b as a list of distinct empty lists. As it is now,
I have to do something like this:
b = [[] for x in range(5)]


in order to get the semantic I want. It's not any great hardship, of
course, but I have been bitten by the [[]] * 5 case and its cousins on
several occasions, and it might be nice if there were a separate
semantic as described above to make it more clear what's going on.


As you point out, there is a (pretty simple) way of expressing exactly
what you want. Inventing some line noise to cover one special case,
would encourage inventing some more line noise to cover the next
special case, which would encourage inventing some more line noise
.... and pretty soon we'd have Perl.

For example, how would extend your idea to disambiguate between the
possible meanings of "[[foo()]] * 5" ?

Now, how about "[[foo()]*5] * 5" ?
Jul 18 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

26 posts views Thread by Axel Boldt | last post: by
10 posts views Thread by Brian Roberts | last post: by
10 posts views Thread by Stefan HŲhne | last post: by
25 posts views Thread by Matthias | last post: by
14 posts views Thread by Dan Jacobson | last post: by
59 posts views Thread by Steve R. Hastings | last post: by
35 posts views Thread by dragoncoder | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.