Attack a sacred Python Cow
bdesth.quelquechose at free.quelquepart.fr
Thu Jul 24 18:24:50 CEST 2008
Jordan a écrit :
>> 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.
> My words aren't as clear as they should be. I mean that Python lets
> *you* do something without documenting, or rather stating to use a
> better term, that your intention is the non-obvious one.
> I'm not
> saying that Python itself lacks documentation for its own behaviour;
> I'm saying it should force you to make your intentions clear and
> visible to someone reading your code when you want to do something non-
One could then answer than, the behaviour of __eq__ / __ne__ being
clearly defined and documented, implementing one without the other - or
in such a way that a != b is different from not(a == b) - is by itself
an explicit 'statement of intention' !-)
>> 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).
> Good, at least we've come to a point in this discussion where I can
> firmly agree with somebody.
On that concrete case, a priori, yes. wrt/ the 'explicit self', there
are in fact two points:
1/ The mandatory use of 'self' to access the current instance.
As far as I'm concerned, and *even if there was no other technical
reasons*, I wholefully, happily and definitively agree with this choice
- specially in a language like Python (it's not quite the same problem
with Java where you just can't put anything outside a class). It's truly
(and IMHO, of course) a case where explicit-is-better-than-implicit,
Strange enough, I never heard of anyone complaining about the mandatory
use of $this-> in PHP. Nor about the mandatory use of @/@@ in Ruby. Nor
about the 'm_whatever' naming convention in C++. Nor about [add your own
2/ The need to explicitely declare the 'target' object (self or cls) as
first param of a 'function-to-be-used-as-method'.
Granted, this one may feel a bit "unfinished" at first. And I would not
bet my life on it, but I think one could possibly find some "solution"
that would not as a side-effect impose any restriction wrt/ the current
OTHO, given 1/, and since the way Python builds "methods" out of just
two more general constructs (the def statement and the descriptor
protocol) is part of what makes it's object model so powerful, I don't
feel like the price to pay to keep the implementation as simple as
possible is too high. IOW, while I would not turn down a "solution" like
the one mentionned above (let's say -0 as far as I'm concerned), I just
don't think it would be worth the time spent.
Anyway, "explicit is better than implicit" is not the appropriate
dogmatic justification here - but a couple other quotes from the
Python's Zen could apply (left as an exercice to the reader) !-)
More information about the Python-list