An oddity in list comparison and element assignment

[michael.f.ellis at gmail.com]

Hey Alex, lighten up! Python is a programming language -- not your
family, religion, or civil rights.
Cheers,
Mike

Alex Martelli wrote:
> <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