[Python-Dev] Prototypes [was: Proper tail recursion]

[Raymond Hettinger]

 [Michael Chermside] 
> I wouldn't say that tail recursion *encouraged* a functional style,
> rather I would say that refusing to accept a working version of
> tail recursion actively *discourages* the use of that style.
> 
> Now, I understand that a functional style is not for everybody. And
> I realize that you want to design Python so that people will continue
> to use it to write programs that are readable (and understandable)
> by everyone. But I believe strongly in allowing different programming
> paradigms -- using procedural, OOP, or functional programming styles
> (and others) for the particular problems that they express best.
> And I think that *discouraging* a functional style by intentionally
> breaking it is a bad idea.
> 
> Rejecting an implementation of tail recursion because it doesn't
> work well or it slows down other cases is perfectly reasonable. But
> rejecting it because it allows some people's programs to work
better...
> that just seems wrongheaded.


All of this has gotten me thinking again about a pending (currently out
of favor) feature request to loosen a syntax rule, with the goal of
helping out people who want to experiment with prototype OO.  The
request is make it possible to write:

    def Account.deposit(self, v):
        self.balance += v

Currently, it has to be written:

    def _deposit(self, v):
        self.balance += v
    Account.deposit = _deposit
    del _deposit

While it seems minor, this little relaxation of rules is essential for
working with prototype OO.  On comp.lang.py, I remember someone posting
a recipe for an object that supported prototype style cloning.  The only
thing missing to make it useable was this syntax change.

Outside of prototype OO, the Lua programming language also offers this
syntax as a way to define functions in a specified namespace.  Their
experiences with it have been favorable.

The reason is the feature request is currently out of favor is the
possibility that the syntax would be abused and people would start
defining their methods outside of class definitions.  

My feeling is that we document a little discouragement and then let
people do whatever they want.  After all, they can already define
methods outside of a class definition, it just takes an extra line or
two as shown above.  We can also take a lesson from the for-loop syntax
which currently allows "for i, a[i] in enumerate(b)".  Though it is
available and easily abused, it has not corrupted the masses.  The
lesson is that the prototype style can be facilitated without mucking up
anything else.


Raymond