Python 3K or Python 2.9?

[Duncan Booth]

Ivan Voras <ivoras at _fer.hr_> 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).