Edward Elliott wrote:
> Holger wrote:
>
>>oops, that was kinda embarrassing.
>
>
> It's really not. You got a completely unhelpful error message saying you
> passed 2 args when you only passed one explicitly. The fact the b is also
> an argument to b.addfile(f) is totally nonobvious until you know that 1) b
> is an object not a module*, and 2) objects pass references to themselves as
> the first argument to their methods. The syntax "b." is completely
> different from the syntax of any other type of parameter.
>
Specifically, perhaps it would be better to say "b is an instance of
some Python class or type".
Objects don't actually "pass references to themselves". The interpreter
adds the bound instance as the first argument to a call on a bound method.
I agree that the error message should probably be improved for the
specific case of the wrong number of arguments to a bound method (and
even more specifically when the number of arguments is out by exactly
one - if there's one too many then self may have been omitted from the
parameter list).
> The mismatch between the number of parameters declared in the method
> signature and the number of arguments actually passed is nonobvious,
> unintuitive, and would trip up anybody who didn't already know what was
> going on. It's ugly and confusing. It's definitely a wart on the
> langauge.
>
Sorry, it's a wart on your brain. Read Guido's arguments in favor of an
explicit self argument again before you assert this so confidently. It's
certainly confusing to beginners, but there are actually quite sound
reasons for it (see next paragraph).
> Making people pass 'self' explicitly is stupid because it always has to be
> the first argument, leading to these kinds of mistakes. The compiler
> should handle it for you - and no, explicit is not *always* better than
> implicit, just often and perhaps usually. While it's easy to recognize
> once you know what's going on, that doesn't make it any less of a wart.
>
Hmm. I see. How would you then handle the use of unbound methods as
first-class objects? If self is implicitly declared, that implies that
methods can only be used when bound to instances. How, otherwise, would
you have an instance call its superclass's __init__ method if it's no
longer valid to say
myClass(otherClass):
def __init__(self):
otherClass.__init__(self)
...
> * technically modules may be objects also, but in practice you don't declare
> self as a parameter to module functions
The reason you don't do that is because the functions in a module are
functions in a module, not methods of (some instance of) a class.
Modules not only "may be" objects, they *are* objects, but the functions
defined in them aren't methods. What, in Python, *isn't* an object?
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Love me, love my blog http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
--
http://mail.python.org/mailman/listinfo/python-list
