Semantics of the empty list

Jacek Generowicz jacek.generowicz at cern.ch
Fri Jul 16 07:02:34 EDT 2004


Dave Opstad <dave.opstad at 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" ?



More information about the Python-list mailing list