"Alex Martelli" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Terry Reedy <[EMAIL PROTECTED]> wrote: > >> <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> > (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 -- http://mail.python.org/mailman/listinfo/python-list
