Unification of Methods and Functions

[Antoon Pardon]

Op 2004-05-22, David MacQuigg schreef <dmq at gain.com>:
> On Sat, 22 May 2004 12:10:51 -0600, "Dave Brueck"
><dave at pythonapocrypha.com> wrote:
>
>>David MacQuigg wrote:
>>> If Python were consistent, and *always* used a special first argument,
>>> there wouldn't be a problem.  The magic first argument would be no
>>> more difficult than magically setting a global variable.  The problem
>>> is that some methods require a magic first argument, and others
>>> require that it *not* be there.  In one case you call cat1.talk() and
>>> in another it is Cat.talk(cat1).
>>
>>But the above explanation misses one very important point: one is used 99.9% of
>>the time, the other 0.1% of the time, if that. Mentioning them side by side
>>like you do implies that they are both equially common, which is not remotely
>>the case.
>
> I can't comment on the usage statistics you cite, but it seems to me
> that unbound methods are more important than these statistics would
> imply.  They are necessary to make the language complete, so you can
> do things that would otherwise require creating an artificial instance
> just to call a method.  Learning Python also treats unbound methods as
> much more "normal" than your argument would imply.
>
>>>  I know this is not terribly
>>> difficult to understand -- one is a bound method, the other unbound.
>>> Still it is a problem for beginners, and it leads to unecessary
>>> complexities like static methods.
>>
>>I don't see how this is at all related to static methods. A method is some
>>piece of functionality that is specific to a particular class. If you have some
>>function already lying around, why would you want it as a method, much less a
>>static method? (I can think of a couple of rather contrived examples, but
>>nothing compelling or common in a normal application - help me out here)
>
> Here is an example from our CDP ( Circuit Design Platform ):
>
> class Bag:
>     def __init__(self, **kwargs):
>         self.__dict__.update(kwargs)
>         
>     def load(infile):
>         strng = infile.read()
>         exec( 'bag = Bag(\n' + strng + ')' )
>         return bag
>     load = staticmethod(load)
>
> We need to load a "statefile" with a deeply nested hierarchy of
> parameters, which will then be represented by a "Bag" of parameters at
> each level of the hierarchy.  The load method needs to be called
> before any Bag exists, so we add the magic "staticmethod" line, and
> don't worry about 'self'.  Sure, we could move the load function
> outside of the Bag class, but that would disrupt the natural structure
> of the program.  The load function is unique to Bags, and it belongs
> in the Bag class.

I don't agree it belongs in the Bag class. The fact that it is unique
to Bags is not an argument for that. I would agree that they belong in the
same module.

IMO you try to cram too much into the class. It seems you want to
put everything in the class that is related to the class. But
sometimes things are related without being a part of it. Writing
a seperate function in the same module makes more sense in that case.

>>I find the current distinction between methods and functions as one that makes
>>quite a bit of sense. It doesn't really cause problems, and I've yet to see a
>>proposal that is cleaner while still making as much sense (IOW, perhaps it IS
>>imperfect, but I can't think of anything better, and apparently nobody else can
>>either).
>
> Have you read the proposal at
> http://www.ece.arizona.edu/~edatools/Python ??  The folks at
> prothon.org also think they have a better solution.  There are some
> good ideas amongst all the crud.  Unification of methods and functions
> is one.  It remains to be seen if they can do this without introducing
> other equally bad complexities.  Smooth the carpet in one place, and
> the wrinkles pop up somewhere else.
>
> When you say the distinction between methods and functions makes
> sense, I assume you mean it has some value to the user.  I would like
> to hear more about this, because I am assuming just the opposite.  In
> my OOP chapter, I rely on the fact that students already understand
> functions.  I use the term "method" only when it is necessary to make
> a distinction.  Otherwise, everything is just a function, and there is
> only one kind.

Well one possible view is that methods are just functions. The
difference being that it is not exactly the function as it
is defined in the class but as related function. Now I don't
know if trying to explain methods from this point of view
would be easier for students to understand and it may cause
confusions of its own. But I think this approach deserves
more attention you seem willing to give it.

-- 
Antoon Pardon