Unification of Methods and Functions

[Dave Brueck]

David MacQuigg wrote:
> >> 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.
>
> Here is a better analogy than my "no-q" functions.  I will use the
> term "global method" to mean any method containing a global variable.
> We now have "normal methods", "static methods", "global methods", and
> a few others.  There is no difference in the calling sequence or the
> header line between a global method and a normal method.  Yet we don't
> seem to have any need for a statement like
> myMethod = globalmethod(myMethod)

Ugh, I'm sorry but this analogy seems as bad as the no-q analogy. That's like
saying methods that contain for-loops should be declared differently - but in
neither case is the thing that matters to the caller - the interface (both the
explict means by which the function is used as well as the explicit or implicit
contract and purpose of the function) - affected. Let's move on.

> I'm new to Python and object-oriented programming.  I make no claim of
> language expertise or vast programming experience.

Doesn't it give you pause that many other people, both with and without that
background, have encouraged you to give the current feature set a chance? As
in, use these features for awhile, get some more experience with them, and in
time you'll come to understand the 'why' behind them? Again, I'm not asserting
that the current language is perfect, just that the way things are might have a
purpose and/or the proposal you've come up with has drawbacks worse than what
we already have... If nothing else, waiting until you have a lot of programs
under your belt will let you argue your point from a position of strength.

> offering a perspective on Python from a technical professional
> (circuit design engineer) who intends to use it as the basis for a new
> design platform, and intends to recommend it to students and other
> technical professionsls who could benefit greatly, but don't have time
> to learn the language as well as they should.

Then what you really ought to do is not cover more advanced topics any sooner
than is needed. Really. Nobody taking an intro-to-programming course needs to
learn about e.g. classmethods. They just don't need to. In your course pass out
a link to a web page of advanced reading for those you want to know more, and
leave it at that. Burdening them with tools they won't use anytime soon won't
be doing them a favor. Instead, teach them how to find answers to their
questions, how to experiment, so that _if_ and when they do come across it then
they can go learn it then.

> >> 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.
>
> OK, here is what I can extract from all this:  Having a separate
> syntax for static methods is beneficial because it tells the
> programmer at a glance that he can call a method from a class without
> having an instance of that class at hand.

That's part of it, but there's more - a static method is used in different
scenarios and for different purposes. They generally aren't interchangeable
beasts.

> >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.
>
> I have shown the 4 function/method forms I'm aware of, and how to
> translate them to a simpler syntax, in Appendix 1 of Prototypes.doc at
> http://ece.arizona.edu/~edatools/Python  Have you read that?

Yes, but as I pointed out elsewhere, it may help to write about this in some
other context than your other proposals (the fact that this is buried in
Appendix 1 under a title of "Translating Python Classes to Prototypes" doesn't
lend itself to much reader traffic).

But, it's better than nothing, so here goes:

1. Bound methods - the calling appears to be identical in either version, but
one of the real values of the bound method form is being able to call the bound
method _when you don't have the instance variable handy_ (I'm just trying to
point out why it's useful). Anyway, the fact that the methods don't have a self
variable does make things seem a little magical - with 'self' in the arg list
it makes sense to me how self.foo grabs a variable from the current instance.
Yes, there is some magic in the current implementation in that the self arg
gets passed in, but the alternative is either uglier or more magical, so it
seems like a good compromise between explicitness and practicality.

2. Unbound methods - the example uses an unbound method to "bypass" a subclass
method - that seems like a really unrealistic example. Inserting the superclass
method into the subclass, but with a different name seems equally odd. Thus,
the whole argument in favor of the "Python 3" version is unappealing. What's
downright frightening, however, is that you can write something like '__self__
= c' and get the same behavior (for many reasons, not the least of which is
that two seemingly unrelated statements are completely linked). Wanting to call
a superclass method with the current instance is a much more likely example,
but with either form of the "Python 3" syntax it's quite unclear that that is
what is happening - because it's indistinguishable from the other calls, it's w
ay less clear what the code is doing. Thus, both newbies and experts alike will
have a more difficult time understanding (and maintaining and modifying) the
code.

3. Static methods - your page doesn't list any examples of calling the
functions, but I assume that in both cases it's Mammal.show(). Not much to be
unified here, although I don't like the fact that the "Python 3" version loses
the information that it is a static method (I don't particularly like the fact
that for the current version the staticmethod call happens after the method
body - I like some of the proposals in the related PEP), but in current Python
you actually have two indicators - there's no 'self' parameter. And again, you
have the same problem in the calling code - it's not clear what is happening,
and yet what is happening is a pretty important piece of info. In the "new"
syntax, the call could be to a static method or to a superclass method, but the
reader of the code is left wondering which one it is.

4. Class methods - this example just seems broken, but perhaps I'm misreading
it. In the Python 3 version, a string is getting passed in to the class method,
and the prototype of the *string* is then displayed - makes no sense to me. In
any case, class methods are IMO a pretty advanced topic - since a main point of
yours is that you want to make OO more accessible to the lay programmer, I
don't see how class methods would come up in the discussion at all - they'd be
more relevant to a metaclass or descriptor discussion.

> I'm also continually adding new examples under the Examples and
> Exercises link on that same page.  Many of these are contributed by
> readers of this thread, including some who would rather not post here.
> (Gentle Request: A little less intolerance from some others on this
> thread might encourage more contributions from people they really need
> to hear from.)

Equally gentle request: don't be too hasty in assuming that because people
disagree with you, their previous experience has clouded their perceptions or
made them forget what it was like to walk the path you're currently on.

> As for a real program, it will be a few months before I have anything
> sizable.  I showed you the statefile example (in response to your
> request), but you seemed to be insulted, like you thought I was
> talking down to you, or something.

Not at all, just realize how your message sounds on the receiving end (whether
you intended it to come across this way or not): "Even though I haven't really
used these features much, I think they should be changed. Other people say the
features have a purpose, and that the purpose becomes clear over time, but I
disagree." That, in itself, is hard to take too seriously, although I'm
impresed at how many people apparently took the time to think about your
suggestion.

Best of luck,
Dave