Unification of Methods and Functions

Dave Brueck dave at pythonapocrypha.com
Sat May 22 14:10:51 EDT 2004


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

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

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

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.

-Dave





More information about the Python-list mailing list