Duncan Booth <[EMAIL PROTECTED]> wrote:
...
> As for omitting 'self' from method definitions, at first site you might
> think the compiler could just decide that any 'def' directly inside a
> class could silently insert 'self' as an additional argument. This
> doesn't work though because not everything defined in a class has to be
> an instance method: static methods don't have a self parameter at all,
> class methods traditionally use 'cls' instead of 'self' as the name of
> the first parameter and it is also possible to define a function inside
> a class block and use it as a function. e.g.
Actually you could do the "magic first-parameter insertion" just when
returning a bound or unbound method object in the function's __get__
special method, and that would cover all of the technical issues you
raise. E.g.:
> class Weird:
> def factory(arg):
> """Returns a function based on its argument"""
>
> foo = factory("foo")
> bar = factory("bar")
> del factory
>
> When factory is called, it is a simple function not a method. If it had
Sure, that's because the function object itself is called, not a bound
or unbound method object -- indeed. factory.__get__ never gets called
here.
> class C:
> def method(self): pass
>
> and
>
> def foo(self): pass
> class C: pass
> C.method = foo
>
> both of these result in effectively the same class (although the second
> one has a different name for the method in tracebacks).
And exactly the same would occur if the self argument was omitted from
the signature and magically inserted when __get__ does its job.
> That consistency really is important. Whenever I see a 'def' I know
> exactly what parameters the resulting function will take regardless of
> the context.
And this non-strictly-technical issue is the only "true" one.
> Another area to consider is what happens when I do:
>
> foo = FooClass()
>
> foo.bar(x)
> # versus
> f = foo.bar
> f(x)
>
> Both of these work in exactly the same way in Python: the self parameter
And so they would with the "__get__ does magic" rule, NP.
> My point here is that in Python the magic is clearly defined and
> overridable (so we can have static or class methods that act
> differently).
And so it would be with that rule, since staticmethod &c create
different descriptor objects.
Really, the one and only true issue is that the Python community doesn't
like "magic". It would be perfectly feasible, we just don't wanna:-).
Alex
--
http://mail.python.org/mailman/listinfo/python-list
