Another try at Python's selfishness

[Donn Cave]

In article <1138918102.863033.298700 at o13g2000cwo.googlegroups.com>,
 n.estner at gmx.de wrote:

> Having read previous discussions on python-dev I think I'm not the only
> Python programmer who doesn't particularly like python's "self"
> parameter:
> 
>     class Foo:
>         def bar(self, a,b):
>             return a+b
>     Foo().bar(1,2) => 3
> 
> The main reason (at least for me) is that there's simply too much
> "magic" in it. Why does the expression left of the '.' get promoted to
> the first parameter? It even goes further:
> 
>     Foo.bar(Foo(), 1,2)
> 
> works, but:
> 
>     Foo.bar(1,2,3)
> 
> doesn't, just because of the "magical first parameter" in a member
> function. But:
> 
>     Foo.__dict["bar"]__(1,2,3)
> 
> Does work.
> 
> The point is, I _do_ think it's a good idea to explicitly write
> "self.SomeMember" for member-access, so I thought: why can't we be
> equally explicit about member function declaration? Wouldn't it be nice
> if I could write (say, in Python 3k, or maybe later):
> 
>     class Foo:
>         def self.bar(a,b):
>             return a+b
>     Foo().bar(1,2) => 3
> 
> That way, the declaration would match the invocation (at least
> syntactically), and the "magic"-feeling is gone. In the long run, the
> "old-style" syntax (i.e. if there's no '.' in the method name) could be
> used for static methods.
> 
> What do you think?

I think you make it too complicated.  Why shouldn't all
functions be declared and called in the same way, that
would be the simplest thing for everyone.

    class Foo
        def bar(self, a, b):
            return a + b
    bar(Foo(), 1, 2) => 3

The virtues of this consistency become more apparent in a
more complex functional context:

    sys.stdin.write(open(file, 'r').read().split(sep)[0])

vs.
    write(sys.stdin, split(read(open(file, 'r')))[0])

   Donn Cave, donn at u.washington.edu