Unification of Methods and Functions

[James Moughan]

Antoon Pardon <apardon at forel.vub.ac.be> wrote in message news:<slrnca10tf.1i9.apardon at trout.vub.ac.be>...
> Op 2004-05-10, James Moughan schreef <moughanj at tcd.ie>:
> > David MacQuigg <dmq at gain.com> wrote in message news:<889t90tdl9o9t25cv5dj6k5rnktuce0jin at 4ax.com>...
> >> On 8 May 2004 07:07:09 -0700, moughanj at tcd.ie (James Moughan) wrote:
> >> 
> >> >David MacQuigg <dmq at gain.com> wrote in message news:<4a9o90pbu122npgf4m2hrgg04g2j0ic6ka at 4ax.com>...
> >> >> On 7 May 2004 06:31:51 -0700, moughanj at tcd.ie (James Moughan) wrote:
>  <snip>
> >> >> Also, if you are calling
> >> >> a function that has an instance variable ( .length ) and no instance
> >> >> has been set by a prior binding, you would need to set __self__
> >> >> manually.
> >> >> __self__ = foo; print FooLen()
> >> >
> >> >???!!!??? 
> >> >
> >> >This is what I was talking about in my first post, global variables
> >> >which change depending on where you are in the code... as I understand
> >> >what you're saying, __self__ will have to be set, then reset when a
> >> >method is called from within a method and the exits.  And __self__
> >> >could presumably be changed halfway through a method, too. I'm sorry,
> >> >I don't see this as being more explicit or simpler.
> >> 
> >> The setting of __self__ happens automatically, just like the setting
> >> of the first argument in a call from an instance.  The user doesn't
> >> have to worry about it.  
> >
> > Explicit is better than implicit, especially in getting people to
> > understand things. :)
> 
> I'm a bit sick of this argument. There is a lot om implicity
> going on in python. if obj belongs to cls then obj.method()
> is syntactic sugar for cls.method(obj).
> 

Well, it is... and it isn't. ``method'' could be bound to cls, cls's
super-class, or to obj itself.

> That looks like
> a big implicite way to handle things in python.

You could look at it like that.  I'd say it's a way of making code
generic, and hiding the workings of a subsystem; lots of good things
in Python wouldn't be possible without this type of abstraction.

> Likewise all those magical methods to emulate numerical
> types or containers or sequences or all ways that allow
> the python programmer to do things implicitely throught
> the use of operators instead of through explicitely calling
> the desired method.
> 
> If implicit is such a negative thing to be avoided whenever
> possible, python would look a lot different and I probably
> wouldn't be using it.

Sure; you have to have some understood conventions.  In effect that's
all any higher-level programming language than assembler is.  IMO, in
the case in point, the explicit self makes OO easier to undersstand;
YMMV, of course, as it does with Dave. :)