An oddity in list comparison and element assignment

[Terry Reedy]

"Alex Martelli" <aleax at mac.com> wrote in message 
news:1hgbjx1.1gn7haipx7x5N%aleax at mac.com...
> Terry Reedy <tjreedy at udel.edu> wrote:
>
>> <michael.f.ellis at gmail.com> wrote in message
>> news:1149277242.199765.213600 at g10g2000cwb.googlegroups.com...
>> > (As an aside, may I point out that Python In A Nutshell states on page
>> > 46 "The result of S*n or n*S is the concatenation of n copies of S".

Alex, in responding to this sentence lifted out of context by Michael, I am 
responding more to him and his claim of 'not strictly the case' than to 
you.  What I wrote is also more a draft of a paragraph for a book of mine 
(of no competition to yours) than a suggestion for a future edition of your 
book.

>> It would be more exact to say that S*n is [] extended with S  n times,

A**b is often explained as 'A multiplied by itself b times' or some such. 
It is more exact to say it is '1 multiplied by A b times'

>> which makes it clear that 0*S == S*0 == []

which makes it clear that A**0, including 0**0, is 1.

>> and which avoids the apparently misleading word 'copy'.

Given the number of people, including Michael, who have posted puzzlement 
based on their confusion as to what does and does not get copied, I don't 
think it unfair to call 'copy' 'apparently misleading.  My intention in 
this phrase is to suggest that one who misunderstands 'copy' in this 
context will be mislead while one who understands just what is copied and 
what is not copied will not.

The point of my code snippet was to explain/illustrate what is copied. 
While it will (obviously) only executive as Python code for lists, I 
believe the algorithm is generic if the initial assignment and list.extend 
method are suitably interpreted.

Of course, I presume that in the CPython code, the actual initialization is 
more like (length one blank value)  * (n*len(S)) followed by n slice 
assignments, but the Python code for this would still be list specific and 
would also be more complex, without much aiding comprehension of the 
result.

Strings are a somewhat special case since the characters in the string are 
not wrapped as Python objects unless and until extracted from the string. 
So one cannot as easily talk about the object(s) contained in the sequence.

> Considering that the very next (and final) sentence in that same
> paragraph is "If n is zero or less than zero, the result is an empty
> sequence of the same type as S", I don't think there's anything
> misleading in the quoted sentence.

In its original context, with respect to that issue, no.  But as I said, I 
was responding to Michael's removed-from-context quotation and his claim 
about the need for a warning.  I wonder if you read down to the end, where 
I asked him whether I had missed anything he might find fault with, before 
you responded.

>  Moreover, since the paragraph is about sequences, not just lists,

This *thread* is about repetition of lists, and in particular, a list of 
one (or more) lists, and the consequences of the mutability of the inner 
lists, and that is the context in which I wrote.

> it *WOULD* be horribly wrong to use the phrasing you suggest:

In a generic context, [] would obviously have to be replaced by 'null 
sequence of the type of S', which in many cases is type(S)().  And 'extend' 
would have to be interpreted generically, as something the interpreter 
would do behind the scenes in type(S). __new__, although as I said before, 
I don't think that is exactly what it does do.

>"bah!"*3 is NOT a list,

Duh.,

> it's EXACTLY the
> concatenation of three copies of that string -- no more, no less.

Depends what one means by 'copy'.  See below for your alternate wording.

>> Or one could say that the result *is the same as* (not *is*) the
>
> I find this distinction, in this context, to be empty padding, with zero
> added value on ANY plane -- including the plane of "pedantry";-).

Perhaps you should tone down the overwrought emotionalism and take a look 
in a mirror.  In *your* response to Michael you made the *same* 
distinction:

>> Can you give me an example where, say, for a sequence S,
>> x = S * 3
>> is not structurally the same as
>> x = copy.copy(S) + copy.copy(S) + copy.copy(S)

I agree that adding 'structurally' makes the 'padding' even better.

>> concatenation of n *shallow* copies of S.  'Shallow' means that each 
>> copy

> I do not think it would be good to introduce the concept of "shallow" at
> a point in the text which is talking about ALL sequences -- including
> ones, such as strings, for which it just does not apply.

Again, I was not suggesting that you do so.  Adding 'shallow' was 
intentially pedantic for Michael's 'benefit'.  To be clear, I was *NOT* 
supporting his warning suggestion.

> But, thanks for the suggestions, anyway!

We both have the goal of expaining Python better so beginners hit fewer 
bumps on the road.

Terry Jan Reedy