Attack a sacred Python Cow

[Bruno Desthuilliers]

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-
> obvious.

<nitpick>
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' !-)
</nitpick>

(snip strawmens)

>> 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, 
period.

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 
example here].

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 
implementation.

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) !-)