Attack a sacred Python Cow

Matthew Fitzgibbons elessar at
Sat Jul 26 06:43:45 CEST 2008

Jordan wrote:
> Well this discussion is chugging along merrily now under its own
> steam, but as the OP I should probably clarify a few things about my
> own views since people continue to respond to them (and are in some
> cases misunderstanding me.)
> I *like* explicit self for instance variable access. There are
> arguments for and against, and my personal opinion is that the
> arguments for are stronger. Local variables and instance variables
> should be explicitly differentiated somehow, for the sake of
> readability. Python's approach works. I slightly prefer Ruby's @,
> because I think the brevity is a net win for something so commonplace
> (is it less readable? Maybe. is "def" less readable than "define"? I
> don't know - I think about 10 seconds of coding in Python or Ruby is
> enough for you to be able to instantly grok def. Likewise, @. The
> argument is more aesthetic IMO - how many perl-style/1337speak pu|\|
> (tu at t10n m at r|<$ can you stand?)
> I have come to dislike explicit self in method argument lists. Sure,
> there are reasons. I don't think they're at all strong enough.
> I'm definitely against the != behaviour, and maybe will get around to
> actually PEPing it.
> The point I was trying to make originally was that applying any mantra
> dogmatically, including Explicit is better than implicit, can lead to
> bad results. Perhaps having Practicality beats purity is enough of a
> reminder of that fact for the Python community :-)
> --

Having followed this entire discussion, I don't think that explicit vs. 
implicit is really the issue. Your own examples, self in the arg list 
and __ne__ not being the negation of __eq__ by default, seem to 
contradict your premise that explicit is dogmatically favored over implicit.

Keep in mind that another core principle of Python is "don't make the 
user type it if they don't have to." As you yourself admit, there are 
very compelling reasons to make the user type self in every method 
argument list, one of which being yet another Python principle, 
readability. Therefore, explicit self didn't come through dogmatic 
adherence to explicit over implicit, but through careful consideration.

As for !=, it seems like there is a technical reason for the behavior. 
Remember, there is no default __ne__ method, so the behavior you want 
would have to live in the interpreter. If __ne__ isn't defined, it would 
have to try to call __eq__ and negate the result. Is there any other 
lookup that is treated this way? It seems like a kludge to add this 
special type of behavior for one case that doesn't seem to bother most 
people anyway.

So really, this is about a couple annoyances you've found in a language 
you otherwise like. And it seems like both can be addressed pretty 
easily. PyLint, for example, already checks that self is the first 
argument of methods. And since it has a plugin system, I'm sure you 
could add a check for __ne__ if __eq__ is defined. You can turn off the 
checks you don't care about and bind it to a key combo in your text 
editor. Those annoying little errors will be exposed very quickly.


More information about the Python-list mailing list