Using function parameters to determine method kind

[Lenard Lindstrom]

In reply Michele Simionato's <michele.simionato at poste.it> posting:
      <95aa1afa.0404070018.c28b43b at posting.google.com>

I apologize that my replies are becoming more difficult to understand.
It is just that I have had to rethink a few things regarding my
initial proposal. So I will just start fresh here.

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. A function's first parameter determines which type
is created at function declaration:

def fs(x): pass # I am a static function
def fi(self): pass # I am an instance function
def fc(cls): pass # I am a class function

If the first parameter is neither 'self' or 'cls' the function
is static by default.

Of course no such scheme is worth proposing if it breaks too much
existing code. Therefore the posting to comp.lang.python. I can
imagine serious breakage only if instance methods are customarily
declared without a first argument 'self'. Instance methods are the
only case where a function's __get__ method matters. In every other
case the function is wrapped in some descriptor class instance
and the function is called directly as an unbound method.
Unfortunately there is an exception to the 'self' naming convension:
the __init__ and __new__ methods of a metaclass. I hoped they were somehow
handled differently from the usual __init__ and __new__ calls of object
instance creation, but they are not. So the 'self' coding convension
has exceptions. I am now convinced my original idea is impractical.

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.

>> All this talk about python functions just being another kind
>> of descriptor makes me wonder if it is not time to revive
>> the idea of having type function subclassable:
>
>You may want to look at this thread:
>
>http://groups.google.it/groups?hl=it&lr=&ie=UTF-8&threadm=95aa1afa.0402262158.5b33de79%40posting.google.com&rnum=1&prev=/groups%3Fhl%3Dit%26lr%3D%26ie%3DISO-8859-1%26q%3Dsimionato%2Bfeature%2Brequest%26btnG%3DCerca%2Bcon%2BGoogle%26meta%3Dgroup%253Dcomp.lang.python.*

I was actually being somewhat serious. It is just the syntax of:

def foo(x):
    __factory__ = staticfunction

that is questionable.

def(staticfunction) foo(x):
    ...

may be more appropriate.

As for that thread you mentioned in you posting on subtyping
FunctionType, here it is:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=mailman.1048519782.21597.python-list%40python.org&rnum=1&prev=/groups%3Fq%3Dgroup:comp.lang.python%2Binsubject:function%2Binsubject:type%2Binsubject:not%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dmailman.1048519782.21597.python-list%2540python.org%26rnum%3D1

I actually did make FunctionType subtypable in a prerelease
version of python 2.3 and it did not crash or act strange.
At the time I made the above posting I was playing with function
currying and tried to extend FunctionType by adding some curry
operators. It didn't work:

"TypeError: type 'function' is not an acceptable base type"

But as the thread continued my ideas on function currying changed
and it seemed less important to subtype function, so my postings stop
making a lot of sense; it became more important to me to have
a consistent way of doing introspection on callables. I made
FunctionType subtypable just to prove a point. I was a
stranger to the Python community and the Unix diff and patch
tools so I did not try to submit a patch. The interpreter has
since dissappeared into my trashbin as newer releases of Python
can out. But if there is enough interest and I have the time I
may try and do it again.

Lenard Lindstrom
<len-l at telus.net>