Unification of Methods and Functions

[David MacQuigg]

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.

See the thread "classes vs dicts" and the discussion following my post
on 5/13 for more on statefiles and Bags. See also
http://www.ece.arizona.edu/~edatools/Python/Statefiles for the latest
on our solution to the statefile problem (how to handle thousands of
deeply-nested setup parameters).

>> The recent discussion on "Method binding confusion" 5/2/04 shows that
>> even experts can get confused.  Here is the example, reduced to its
>> simplest terms:
>[snip example that IMO doesn't reflect any sensical use case]
>> How would you explain this to non-CIS students in a class on circuit
>> design, where there is very little time to discuss programming?
>
>What kind of an instructor would bring this up in an introductory programming
>course? If you're short on time, there are oodles and oodles of more commonly
>used topics to cover.

Seems like my challenging statement was misleading.  I have no
intention of bringing up strange binding problems in an introductory
class.  This was a challenge to those who think that Python's binding
syntax is simple.  Even an example as strange as this would be no
problem for a student if the new syntax were adopted.

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

>Most importantly, I've yet to see it cause any real or lasting problems for
>beginners - either (1) nobody cares unless you point it out and make an issue
>out of it, or (2) they ask, you take 30 seconds to explain it, and they say,
>"oh, ok" and move on. Occasionally someone particularly bright (and/or with
>experience in certain other languages) will really grasp the 'why' behind the
>difference, and you'll see the light go on as they begin to understand the
>power available to them.

I think there is a tendency to assume that whatever you have learned
is just the way things have to be.  I was assuming that about Python
until someone prodded me to look at Ruby.  That got me interested in
other languages, like Prothon.  It wasn't until I looked at Prothon
that the light came on regarding this unification issue.  Until that
time, I was assuming, like everyone else, that static methods, lambda
functions, and lots of other warts were fundamentally necessary.

The best introductory text on Python is Mark Lutz' Learning Python,
2nd ed.  He takes 96 pages to cover OOP, and he doesn't waste time on
unnecessary topics like metaclasses.  I believe an improvement in
Python's syntax could make it possible to cut the number of pages in
half, and still reach the same level of proficiency in solving
real-world problems.  Why is it we can see there is clutter in Perl,
but we can't see it in Python?

-- Dave