Ivan Voras <[EMAIL PROTECTED]> wrote:
>> I'd say Mr Eckel fails to graps some of the great points about
Python's
>
>> object model - the rant about the use of 'self' is a sure clue.
>
> What does "self" have to do with an object model? It's an
> function/method argument that might as well be hidden in the compiler
> without ever touching the role it has (if not, why?). I agree that
it's
> needless noise in a language.
You could add some syntax to Python such that '.x' was equivalent to
'<first argument of current function>.x' (either completely implicitly
or with some surrounding block that lets you specify the assumed
variable.
That wouldn't break anything in the syntax but the general feeling of
the Python community is that such a change would be undesirable as it is
better to write the variable name out explicitly.
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.
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
gained an extra parameter then either you would have to explicitly pass
it an instance of a not yet defined class when calling it, or the
compiler would have to somehow know that it had been defined with the
extra parameter and add it.
Basically it all boils down to having a consistent set of rules. Ruby
has one set of rules, but Python has a different set. Python's rules
mean you can interchange functions and methods more easily [at a cost of
having to write self out explicitly/with the advantage that you can
easily see references to self](delete as preferred). There is no
difference between:
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).
That consistency really is important. Whenever I see a 'def' I know
exactly what parameters the resulting function will take regardless of
the context.
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
is bound to the method when you access 'foo.bar', not when you make the
call. That isn't the case in some other scripting languages. e.g. in
Javascript the first one would call bar with the magic 'this' parameter
set to foo, but in the second case it calls bar with 'this' set to the
global object.
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).
--
http://mail.python.org/mailman/listinfo/python-list
