Unification of Methods and Functions

[David MacQuigg]

On Mon, 24 May 2004 14:28:28 +1200, Greg Ewing
<greg at cosc.canterbury.ac.nz> wrote:

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

It's about 2% if you just count pages.  The problem with just counting
pages or number of calls is that doesn't tell you whether those few
calls are really important, or just a little sugar for something that
could be done with more normal methods.  If you want to count
something, I would say the percentage of programs which make use of a
particular feature is more meaningful than the number of times it is
used in the program.  You still have the problem of finding a
representative sample of programs.  Even the Python libraries would
give you skewed stats if you are looking at a new feature.

The number of 'global' statements is probably less than 1% of all
lines of code ( just guessing ), but I don't think anyone would assume
they are unimportant.

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

I would rather not use modules to package individual classes just
because we are trying to avoid static methods.  I'm using modules for
a much larger grouping of classes and data (e.g. everything related to
a particular simulator or display tool).  Much easier to just add the
staticmethod line wherever needed, and be done with it.

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

How can we say that this little snippet wasn't distilled from a larger
program in which the structure makes sense?  I've posted this question
in the thread from which the example came, since this appears to be an
important question to many in this thread, and only the OP knows for
sure if it was something real or just an attempt to throw a curve ball
using Python's binding syntax.

My only conclusion is that even wierd examples like this are no
problem with a simpler syntax.  A good language has a simple syntax
that is so versatile, you can put things together in many
unanticipated ways, and they work exactly as you would expect.

In my original solution to the statefile problem, I had classes nested
ten levels deep -- no methods, just "bags" of data.  It started the
expert I was working with, but it worked surprisingly well.  Simple,
versatile building blocks is what I like about Python.  I can figure
out the high-level stuff myself.  I don't need somebody's "design
pattern".

-- Dave