Unification of Methods and Functions

[Dave Brueck]

David MacQuigg wrote:
> >> 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.
>
> I would agree if you cut out two of the "ways" in this sentence. :>)

Well, for kicks I looked at the standard Python library, since I figured it
would have the greatest concentration of unbound method use (my reasoning was
that since it was a library more than a consumer of a library, you'd have lots
of class hierarchies and therefore more occurences of unbound method calls to
super classes. Even in this situation it appears that unbound method calls are
less than 2% of all method calls. The real point is simply that unbound method
calls are pretty rare.

> Still this is like saying names that start with the letter 'q' are way
> less common than all other names, so it is OK if we have a special
> form for functions with such names.

Not at all - that's a flawed analogy because variable names can be pretty
arbitrary and interchangable. The different types of function calls, method
invocations, whatever, are neither arbitrary nor interchangable.

> I've never stated or implied that unbound methods are as common as
> bound methods.  Nor would I say that confusion abounds.  The different
> calling sequences are just an unnecessary complexity that trips up
> some new users, especially those that don't have experience in some
> other OOP language.

I'm beginning to understand the real root of the disagreement - you see no
value in the differences and therefore see the existence of the differences as
a flaw. But that's just the problem: these are not merely syntactic
differences, but they are semantic - they are different in purpose and in use,
so your suggestion to get rid of them seems very unappealing: from my
perspective you are removing something useful from the language to solve a
"problem" that I've yet to encounter, or seen anyone else encounter (including
new users of the language).

> ><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.
>
> I think you have not understood the proposal.  It is *not* necessary
> in the new syntax to know the difference between a static and
> non-static method.  There *is* no difference.  A "static method" (a
> function without instance variables) simply ignores __self__.

And this is why the proposal seems so lousy: the difference between a static
and a non-static method is _not_ just a syntactic difference, their existance
is not _caused by_ the syntax. The syntax merely reflects that they are
different things to begin with. They are different tools, different features -
you use them for different things, so making them appear identical to the
maintainer of the code and the caller of the code seems like a really bad
idea - a maintenance nightmare. If you remove any syntactic difference, then
that information is lost from the code itself. But since that info is useful,
people will instead track that info in comments or something - yuck.

> The differences are an artifact of the syntax, not any fundamental
> difference in purpose.  Normal methods have a special first argument.
> Static methods do not.  That's all there is to it.

No, no, no - they are different tools, plain and simple. The difference just
isn't skin deep - changing the syntax won't make them go away, it'll instead
make the language more ambiguous. Without meaning to be offensive, I must ask:
how much have you actually used any of these features you're interesting in
consolidating? (static method, unbound methods, bound methods, etc.)

> If there is were some fundamental purpose to static methods, there
> would be something they can do that can't be done with the proposed
> simpler syntax?

That's just my point: after consolidating the syntax, static methods will still
exist, but there will be no way of knowing which ones are static and which ones
aren't _without reading every line of the code_ - there will be no syntactic
way to express the idea. Egads!

> I may be wrong, but it looks to me like there *are* no benefits of the
> current binding syntax over the proposed syntax.

Yes, I understand that it looks that way to you, but why is it that so many
people who have used the language for a long time disagree with you? Is it
because everyone else has blinders on? Could it be _possible_ that these
features have value and/or that the solution you propose is worse than what
currently exists? Again, how much did you use the language before coming to the
conclusion that you have?

> What are the benefits of the current design?

I guess my real gripe with the proposal is that it takes what is currently
clear and makes sense and combines it in such a way to make it ambiguous to
everyone involved with the code. The features you propose consolidating really
are different in real programs, and making them all look the same just for the
heck of it doesn't seem to make much sense.

> What can you do in the current syntax that can't be done more easily in the
proposed syntax?

Understand my code 6 months from now. Modify the code with less risk.
Understand the level of intent in someone else's code I'm using.

> Show me some code, and I will show you the equivalent in "Python 3".

No, that burden is on your shoulders, as everyone not in favor of your
suggestions can let the thread die off and nothing will change. <0.5 wink> In
another thread I suggested you take the time to learn what the 2 or 3 most
common uses are for each of the features that will be affected, and show both
the implementation and use in current Python and after your proposed changes.
Not only will doing this give a clear example to everyone, it'll also show that
you are at least aware of how the different function/method forms are used
today in _real programs_ and not contrived examples - after re-reading some of
your comments I have my doubts.

> >> 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,
>
> The Principle of Least Surprise has always been one of my favorites.
> It's a shame this principle offers us so little guidance in resolving
> a simple issue like this unification question.

All of those guiding principles are subjective, but IMO it's pretty clear here
:)

> us in opposite directions.  I think the difference may be in our
> backgrounds.  You seem quite comfortable with Java, so I would guess
> these different method forms fit with what you have learned there.

I abhor Java, actually, and I'm not even sure how to do the bound method form
in Java (or C++, which is where my background lies more than Java).

> I need to feel like I understand what is going on.  I'm not
> comfortable with a bunch of arbitrary rules

Please understand that these are not arbitrary. The fact that you think they
are arbitrary makes me wonder if you really understand them. Don't be offended!

> especially if I
> frequently run into cases where forgetting the rules can cause a problem.

What I like about the current syntax, is that you don't really need to memorize
any rules because how you call them is pretty obvious, unless of course you're
not thinking about what you're doing, in which case there are bigger problems
at hand. For example, when I learned Python I never came across some tutorial
showing how to do an unbound method call - I got to the point where I needed
it, I tried the most obvious thing, and it worked. Likewise, the first time I
needed to get a reference to a bound method, I was impressed that the first
thing I tried worked (impressed with the language, not with myself :) ).

> I need specific examples of problems introduced by the new syntax, or
> of something the old syntax can do better.  We can argue general
> principles forever, but one good example will settle this question.

Like I said, if you really are interested in making headway with your proposal,
*you* need to demonstrate through some non-contrived examples that you
understand how things work today. I've read the pages on your site and either
they don't show all cases that will be affected, or the examples are too buried
by other changes so I missed them. So, show a few examples of how bound methods
are implemented and used today in Python, and how they'd be used and
implemented the new way. Show a few examples of how unbound methods are
implemented and used today, etc. Just showing one example and stating that
everything will be like that glosses over the fact that these things are all
used in very different ways today, and leaves the reader wondering if you have
really thought things through.

> We can learn a lot by looking at
> how languages designed *after* Python have tried to improve on it.

Look at the changes to Python, especially over the past few years - many of the
features are publicly credited as having come from other languages.

-Dave