[Python-Dev] Prototypes [was: Proper tail recursion] (original) (raw)

Raymond Hettinger python at rcn.com
Fri Jul 16 03:22:25 CEST 2004

[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

More information about the Python-Dev mailing list