Unification of Methods and Functions

[David MacQuigg]

On 25 May 2004 07:39:49 GMT, Antoon Pardon <apardon at forel.vub.ac.be>
wrote:
>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:
<snip>
>>>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.

I think we need to trust the programmer who wrote the class as to the
right place to put the load function.  He is the only one who can
organize the best overall structure of modules and classes in the
context of his entire system.

>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.

In this case there is only one other method in the class ( save ), and
it forms a neat, self-contained package.  Moving load to the module
level just so we can avoid the staticmethod line may put it in a
namespace that is already crowded with a bunch of other similar
things.  We also need tricks like adding "bag" to the function name,
or putting the load function right next to the Bag class, so future
programmers will notice that the function is for Bags only.

>>>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.

I don't feel I can make much improvement on Learning Python, 2nd ed.
I think this is the same approach that you are talking about -
functions first, then methods, one variation at a time.

-- Dave