Using function parameters to determine method kind

[Robert Brewer]

Lenard Lindstrom wrote:
> When I first posted my question on using a function's first parameter
> to determine method kind I had a very specific idea on how to
> implement it in Python. Type function becomes subtypable and several
> builtin subtypes are made available. The root type has no __get__
> descriptor method so is a static method by nature. It has two subtypes
> having __get__ methods: an instancefunction is what we now 
> call FunctionType, and a classfunction.
>8 
> My example module 'dparams.py' uses a metaclass to wrap functions in
> staticmethod or classmethod descriptors at class creation,
> but I consider this a less than ideal solution. And to implement
> it in Python means that 'object' can no longer be of type 'type'.
> I believe this is unacceptable. So I consider the issue of using
> parameters to determine method kind closed.

...it would not be a "less than ideal" solution, IMO, if it were built
into 'type' itself, rather than a metaclass. This is the foundation for
my recent crack at the decorator problem:
http://mail.python.org/pipermail/python-dev/2004-April/044151.html,
which uses metaclasses as you indicate, but hopes for a day where the
same functionality would be provided without using metaclass, being
rather an integral part of the builtins "function", "classmethod",
"staticmethod", etc. It currently uses the metaclass to lazily bind the
actual function block to the function name, but a metaclass is not the
only (future, possible) way to do so.

> I made FunctionType subtypable just to prove a point...
> But if there is enough interest and I have the time I
> may try and do it again.

I'd be interested...mostly because I like clean syntax and all of the
proposed syntaxes for decorators are ugly IMO. :(


Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org