Method binding confusion

[David MacQuigg]

On Sat, 22 May 2004 14:10:28 -0600, "Dave Brueck"
<dave at pythonapocrypha.com> wrote:

>David MacQuigg wrote:
>> All functions and methods *should* be unified.  See the section
>> "Unification of all function forms" in PrototypeSyntax.doc at
>> http://www.ece.arizona.edu/~edatools/Python
>
>That's cool that you've taken the time to gather your thoughts onto some pages
>that anyone can view. One thing that might make them even more useful to
>illustrate your point would be to have a page that shows unification in the
>absense of the other changes you're proposing (in the page listed above, the
>reader has to set aside prototypes and miscellaneous syntax changes and try to
>focus on just function/method unification).

I wrote a short example in the first post of the "Unification of
Methods and Functions" thread -- how unification would look without
the other changes.  I also made some notes in the OOP Chapter --
showing that I plan to drop the "classless prototype" stuff in the
next revision.

>Also, such a page would really benefit from a few simple but uncontrived
>examples of how things work now, and how they'd work after your proposed
>changes. From reading that page, I'm not entirely sure how the tasks I
>currently solve with bound methods, unbound methods, static functions, etc.
>would work under the new system - many people learn best by example, but that
>page illustrates (as far as I can tell) how only one method of calling would be
>affected, and the example is obscured by unrelated syntax languages.

There are some short ( contrived ) examples showing how to translate
each of the four function/method styles to the new syntax in Appendix
1 of Prototypes.doc at http://ece.arizona.edu/~edatools/Python  I'm
also planning on translating all the examples people have submitted
for my Examples and Exercises under the same address.

>So, for example, find the two or three most common use cases of unbound
>methods, and simplify the examples to make them concise but not so far that
>they becomes overly contrived (in the math example you've posted a few times, I
>have a hard time imagining why I'd ever want to do that, so to me it's not very
>compelling). Show the code for the implementation as well as how the calls
>happen. Then show the same for how things would look after your changes. Repeat
>this whole process for all calling conventions that would be affected.
>
>Short of this, the ability to convince people will be limited - the problem you
>cite doesn't seem to affect me much in day-to-day development, and I haven't
>seen it be a big hangup for people learning the language (most don't
>notice/care, the rest get past it almost instantly with the simplest of
>explanations). If on top of that it's also unclear to me how I'd get the same
>things done if the language were changed (and it _is_ unclear to me), then it's
>hard to maintain interest in this topic.

I'm getting exhausted myself.  I'll post again in a few months.  Looks
like there is no rush in planning for Python 3.  Meanwhile, those who
are interested can check on the page above for anything new.

-- Dave