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|\|
([EMAIL PROTECTED] [EMAIL PROTECTED]|<$ 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 :-)
--
http://mail.python.org/mailman/listinfo/python-list
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.
-Matt
--
http://mail.python.org/mailman/listinfo/python-list
