Unification of Methods and Functions

[Dave Brueck]

David MacQuigg wrote:
> >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.

All I'm saying is that for most programs, the bound method form is way, way,
way more commonly used than is the unbound calling form.

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

I don't disagree that they are necessary to make the language complete, but
over and over again you have posted examples of the form "here's a bound method
example, here's an unbound method example. They're different". Yes, they're
different, but presenting them that way makes it sound like you normally have
an equal mix of bound and unbound method calls, and that the difference is so
subtle that confusion abounds. Neither is true in practice.

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

<sigh> I know what static methods are _for_, but I don't see what is
necessarily complex about them, nor how your proposed unification would help -
in fact, ISTM that it would make it much more confusing because both the
implementor and caller of the code would never be quite sure if the method was
a static one or not, and that's something that needs to be known by both
parties.

Perhaps we both dislike the current staticmethod syntax of Python, but IMO
making a static method look the same as a non-static method seems like a very
wrong thing to do. They are quite different in purpose and construction, so to
me it doesn't make sense that they should look the same in implementation OR in
usage. See, to me it makes sense that there's no 'self' in a static method -
since there's no instance for it to refer to. Likewise, it makes sense to me
that there _is_ a self in a bound method, else member variable lookup would be
magical (certainly more magical than the fact that a bound method knows what
instance it belongs to).

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

Yes - I suggested the basis for your current solution. :)

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

I'd say that first and foremost, it's powerful, and then simple. The example
IMO shows an abuse of the power without a good reason to do so (my reaction to
the example as "you're doing something odd for no good reason, and you get odd
behavior, so what?"). The proposed unification does not seem to take into
account the benefits of the current design - whether by choice or ignorance I
don't know.

> Have you read the proposal at
> http://www.ece.arizona.edu/~edatools/Python ??

Yep.

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

Yes it has some value, but more than that: it fits the brain quite well. IMO it
adheres to the principle of least surprise, if you are really thinking about
what is going on (and this is why I haven't found it to be a problem for
newbies, because they usually _aren't_ that interested in precisely what is
going on). And if you're not really thinking about what is going on, it places
a pretty minimal burden on you - there's only a handful of rules a blissfully
ignorant programmer needs to adhere to, and that's pretty amazing. But once you
do understand what is going on, then you can do some pretty powerful things
that you can't do in e.g. Java (at least not directly and not without a lot of
work).

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

Maybe, but I'm not arguing that the way things are is the way things have to
be - I'm arguing that (1) the current way is better than all other proposals to
date and (2) the specific proposal you've put forward introduces more problems
than it solves and possibly results in a less powerful language (but I'm not
sure because I haven't seen examples of how all calling use cases would be
affected).

> 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

But has Mark told you that his goal was brevity? I bet you could cut the pages
in half without ANY changes to the language, not because he did a poor job (he
obviously didn't) but because you have different goals in mind.

> Why is it we can see there is clutter in Perl, but we can't see it in Python?

Nobody is taking that stance, as far as I can tell.

-Dave