Unification of Methods and Functions

[Greg Ewing]

David MacQuigg wrote:
> On Sat, 22 May 2004 12:10:51 -0600, "Dave Brueck"
>>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.
> 
> 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. ... Learning Python also treats unbound methods as
> much more "normal" than your argument would imply.

The only time you really need to deal with unbound methods
is when making super calls, and that accounts for maybe
1% or less of all method calls in the code I write.

I haven't seen what Learning Python says about unbound
methods, but if it puts any more emphasis on them than
this, it's putting too much emphasis on them.

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

The Pythonic way to handle this is to create a module
to hold the Bag class and any functions related to it,
e.g.

   # module bags

   class Bag:
      ...

   def load(infile):
     ...

   # in some other module
   import bags
   my_bag = bags.load("my_settings.ini")

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

But seeing as your example did something you're not meant to
be doing in the first place, I don't see how any conclusions
can be drawn from it about simplicity or complexity in
everyday programming.

-- 
Greg Ewing, Computer Science Dept,
University of Canterbury,	
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg