Multi-dimensional list initialization

Andrew Robinson andrew3 at r3dsolutions.com
Wed Nov 7 20:51:48 CET 2012


Hi IAN!

On 11/06/2012 03:52 PM, Ian Kelly wrote:
> On Tue, Nov 6, 2012 at 3:41 PM, Andrew Robinson
>
> The objection is not nonsense; you've merely misconstrued it.  If
> [[1,2,3]] * 4 is expected to create a mutable matrix of 1s, 2s, and
> 3s, then one would expect [[{}]] * 4 to create a mutable matrix of
> dicts.  If the dicts are not copied, then this fails for the same
> reason
:) The idea does create a multable list of dicts; just not a mutable 
list of different dicts.
>
>>>       Q: How about if I use delegation to proxy a list?
>>>       A: Oh no, they definitely won't be copied.
>> Give an example usage of why someone would want to do this.  Then we can
>> discuss it.
> Seriously?  Read a book on design patterns.  You might start at SO:
>
> http://stackoverflow.com/questions/832536/when-to-use-delegation-instead-of-inheritance
:)  I wasn't discarding the argument, I was asking for a use case to 
examine.

I know what a delegation *is*;  but I'm not spending lots of times 
thinking about this issue.
(Besides this thread just went more or less viral, and I can't keep up)

I have a book on design patterns -- in fact, the one called "Design 
Patterns" by Gamma, Helm, Johnson, Vlissides.  (Is it out of date 
already or something?)
>> Please link to the objection being proposed to the developers, and 
>> their reasoning for rejecting it. I think you are exaggerating. 
> > From Google:
>
> http://bugs.python.org/issue1408
> http://bugs.python.org/issue12597
> http://bugs.python.org/issue9108
> http://bugs.python.org/issue7823
>
> Note that in two out of these four cases, the reporter was trying to
> multiply lists of dicts, not just lists of lists.
That's helpful. Thanks.  I'll look into these.

>> Besides, 2D arrays are *not* rare and people *have* to copy internals of
>> them very often.
>> The copy speed will be the same or *faster*, and the typing less -- and the
>> psychological mistakes *less*, the elegance more.
> List multiplication is not potentially useful for copying 2D lists,
> only for initializing them.  For copying an existing nested list,
> you're still stuck with either copy.deepcopy() or a list
> comprehension.

Yes, I totally agree.
But, as far as I know -- the primary use of list multiplication is 
initialization.
That was my point about the most compact notation ought to be for the 
most common case.
Initialization is a very common use case.

List comprehensions are appropriate for the other's.
Even D'Aprano thought the * operator was not a common operation; and I 
suppose that when compared to other operations done in a program 
(relative counting) he's correct; most programs are not primarily matrix 
or initialization oriented.

>
>> It's hardly going to confuse anyone to say that lists are copied with list
>> multiplication, but the elements are not.
>>
>> Every time someone passes a list to a function, they *know* that the list is
>> passed by value -- and the elements are passed by reference.  People in
>> Python are USED to lists being "the" way to weird behavior that other
>> languages don't do.
> Incorrect.  Python uses what is commonly known as call-by-object, not
> call-by-value or call-by-reference.  Passing the list by value would
> imply that the list is copied, and that appends or removes to the list
> inside the function would not affect the original list.
Interesting, you avoided the main point "lists are copied with list 
multiplication".

But, in any event:
_Pass_ by value (not call by value) is a term stretching back 30 years; 
eg: when I learned the meaning of the words.  Rewording it as "Call by 
value" is something that happened later, and the nuance is lost on those 
without a very wide programming knowledge *and* age.

In any event:
All objects in Python are based on pointers; all parameters passed to 
functions, etc, are *copies* of those pointers; (by pointer value).

I made the distinction between contents of the list and the list object 
itself for that reason; I gave an explicit correction to the _pass_ by 
"value" generalization by saying: ("the elements are passed by reference").

The concept I gave, although archaically stated -- still correctly 
represents what actually happens in Python and can be seen from it's 
source code(s).

The point I am making is not generally true of everyone learning 
Python;  For some people obviously learn it from scratch.  But, for 
people who learn the language after a transition, this is a common FAQ; 
how do I modify the variables by reference and not by value; -- the 
answer is, you can't -- you must embed the return value in another 
object; parameters are always passed the *same* way.

Every function written, then, has to decide when objects are passed to 
it -- whether to modify or copy the object (internals) when modifying 
it.   That's all I meant.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20121107/5cfc712c/attachment-0001.html>


More information about the Python-list mailing list