An oddity in list comparison and element assignment

[Alex Martelli]

<michael.f.ellis at gmail.com> wrote:
   ...
> (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". It
> might be well to put a warning in a future edition that this is not
> strictly the case.)

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)

...?  That is, where the "* 3" on a sequence is NOT the concatenation of
three copies (ordinary copies, of course!) of that sequence?  I don't
think you can... and I can't repeatedly explain or point to the
distinction between normal, ordinary, shallow copies on one side, and
"deep copies" on the other, every single time in which that distinction
MIGHT be relevant (because some reader might not be aware of it); such
endless repetition would bloat the Nutshell totally away from its role
as a CONCISE desktop reference, and seriously hamper its usefulness
(particularly by DESTROYING any trace of usefulness for anybody who's
finally *GOT* this crucial bit, but not just in that way).


> languages and methodologies.  As I noted in an earlier reply, I don't
> realistically expect Python to change the behavior of the == operator.

Then you might have avoided trying to convince anybody, or even trying
to IMPLY, that in an ideal version of Python == *SHOULD* behave your way
-- Python's semantics *ARE* entirely up for rediscussion at the moment,
with an eye on the future "Python 3000" release, so this is one of the
very rare periods of the history of the language where backwards
incompatibility of a potential change is _NOT_ a blocking point.

By asserting that your version of == would be "more natural", and trying
to defend that assertion by vague handwaving references to maths and
"real world", you managed to entirely shift MY mindstate (and possibly
that of several other discussants) into one of total and absolute
opposition to the proposal -- having by now spent considerable time and
energy pondering and debating the issue, I am now entirely convinced
that a language with such an == operator instead of Python's current one
would be such a total, unadulterated disaster that I would refuse to use
that language, no matter what other "good" features it might present to
me.  I've walked away from great jobs, just because they would have
required me to use some technology I just could not stand, more than
once already in my life: and this IS how strongly (and negatively) I
feel about your claim that, for built-in ==, your semantics would be in
any way preferable to Python's.

By managing to thus focus my mindset (and make me spend my energy and
time) in opposition to your claims of "more natural", you have at least
managed to ensure that I will not now lend any scrap of help or support
to your debugging needs.  If you were as pragmatic as you claim to be,
this kind of consideration WOULD have weighed highly in your choices.

I.ie., if you had WANTED to attract any such support and help, a
completely different attitude than that "most natural" claim would have
been ENORMOUSLY more productive -- and your continuing attempts to
debate that issue aren't helping AT ALL either:

> I do think that a problem arose when it was adopted from C and extended
> to allow comparison of containers.  In C, you can use it to compare
> integers, floats, and pointers and everyone understands that p==q does
> not imply *p == *q.

If that is so, then everyone is utterly, totally, entirely, horribly
*WRONG*, because, in C, p==q ***DOES*** imply *p == *q (whenever p --
and by consequence q, given equality -- may legitimately be
dereferenced: p == q == 0 does not imply anything about *p and/or *q,
which may produce random results, crash the process, or whatever -- of
course).

You no doubt meant to say something entirely different from what you
ACTUALLY said, but I respectfully suggest you spare your breath rather
than keep trying to defend an indefensible position.

I do NOT agree, and I cannot imagine any state of the world that would
get me to agree, with your claim that "a problem arose" by allowing
equality comparison of containers in Python (many other languages allow
such comparisons, BTW; I would consider it a horrible wart if a language
claiming to be "higher level" did NOT).  That you're "supporting" (HA!)
your absurd claim with an equally absurd (and obviously, wholly false,
unfounded, and misplaced) claim about C pointers doesn't "help", of
course, but even perfectly accurate claims about C (or machine code, or
Cobol, or RPG...) would be pretty much uninteresting and irrelevant.

> Moreover, compilers issue warnings about
> comparisons between different types.

Some do, some don't, depending on the case -- e.g., I do not believe
that even with -Wall (or the equivalent setting) any C compiler whines
about EQUALITY comparisons of signed and unsigned integers (as well they
shouldn't, of course)!

And, just as of course, this umpteenth side-path you're introducing has
really nothing to do with the case, since when you're comparing two
lists-containing-lists which are equal by Python's rules but according
to your original claims about what's "more natural" ``should not'' be,
you ARE anyway comparing object of equal types.

> Basically, I'm looking for simple diagnostic tools that make it easy to
> understand what's really going on when code produces an unexpected
> result.  A 'strengthened equivalence' operator, to use your terminology
> would have been useful to me.

A *FUNCTION* performing such checks in a debugging and diagnostics
package would have been -- and if you hadn't pushed me to spend so much
time and energy defending Python's design choices against your claims
that other choices would be "more natural", you might have gotten help
and support in developing it.  But you chose to make ill-founded claims
of "more natural", and therefore you got a flamewar instead: your
choice.

> will serve to move the discussion beyond terms like 'crazy' and
> 'handwaving' and 'ill-founded'.  I haven't used such perjoratives in
> any of my posts and would appreciate the same courtesy.

You claimed that Python's semantics are "contrary to one of my
fundamental expectations", "an oddity", resulting only (you said in your
second post) from a "performance and memory optimization", and tried to
justify this severe criticism of Python by vague (i..e, "handwaving")
appeals to analogies with "maths" and "the real world".

I do not believe that such scathing criticism had any sound foundations,
nor that calling it "ill-founded" is anything but a fittingly accurate
description: and a language where the == operator DID satisfy the
constraints you claimed to desire for *THE EQUALITY OPERATOR ITSELF* (as
opposed to, for some helper/checker function in a separate module for
checking and debugging) would be a crazy one indeed.  If my opinions
that, I believe, accurately reflect the facts of the case, sound
"pejorative" to you, well, that's not a matter of choice of words on my
part, as much as of your choice of what to express in the first place.

Take your recent claim that in C "everyone understands that p==q does
not imply *p == *q"; which of the many ("pejorative") adjectives I
tagged your assertion with do you think are inaccurate or inappropriate?
I called it wrong, absurd, false, unfounded, and misplaced, and seasoned
the mix with a choice of adverbs including "utterly" and "horribly".  It
appears to me that each of these adjectives and adverbs is appropriate
and accurate (though it's repetitious on my part to use them all, that
repetition does convey the intensity of my opinions in the matter).

This is a factual issue where it's easy to defend strongly held opinions
(which may be checked against "facts"); in matters of "should" (what
semantics "should" a certain language construct HAVE, in order to be
most natural, simplest, and most useful -- quite apart from any issues
of optimization) such ease is, alas, not given... but the fact that
veryfying clashing opinons about what "should" be the case is way harder
than opinions easily checkable against "facts", does not mean that the
"should"'s (which are even more important, potentially, in their effect
on future language design!) are any less important -- on the contrary.


I do not believe I am going to follow this thread any more; I wish you
best of luck in your future endeavors -- and, if you can get back to
being the pragmatist that you claim to be, perhaps in the future you may
chose to express your debugging needs and desiderata in ways that
dispose the experts on some give technology to help and support you,
rather than to fight against the damage which, they opine, it would
cause to the future of that technology if certain ("crazy") suggestions
were to be part of it.


Alex