Jordan a écrit :
OK, it seems my original reply to Bruno got lost in the Aether
(apologies therefore if a paraphrased "quantum duplicate" of this
message is eventually forthcoming.)
Torsten has adequately responded to his second point,
Not MHO, by far.
so I need only
replicated what I said for the first.
Please get your facts, the behaviour *is* actually fully documented:
I have the facts. I know full well the behaviour is documented
Then why do you write, let me quote:
"""
(snip) coding __eq__ (snip) buys you
nothing from the != operator. != isn't (by default) a synonym for the
negation of == (unlike in, say, every other language ever); not only
will Python let you make them mean different things, without
documenting this fact - it actively encourages you to do so.
"""
- it
was pointed out at the time of the original discussion. Documenting a
confusing, unintuitive design decision (whether its in a programming
language, an end user GUI app or anything in between) doesn't justify
it.
I was not commenting on the actual design choice, just stating that it
is actually documented.
To attack a strawman: "foolanguage uses the bar IO library; printing
to stdout takes about 10 mins on the average machine. But thats ok,
because look, its documented right here."
And you're talking about strawman ??? Come on, you obviously can tell
the difference between a one-line statement and your above strawman
argument, don't you ?
Please understand that I'm not arguing about this particular design
choice (and FWIW, I'd mostly agree on the point that having a != b
different from not (a == b) is actually a wart). I'm just correcting
your statement about the behaviour of __eq__ / __ne__ not being
documented, which is obviously false.
(snip)
--
http://mail.python.org/mailman/listinfo/python-list
