unexpected behaviour in class variables

[Andrew Dalke]

Gordon McMillan:
>It ain't wrapped. Beat up Fred, he needs it <wink>.


Beat him up?  I'm a software guy and try to stay away from that
whole hardware concept.  How about I email him instead?

>Functionally, the difference is the need to provide an arg to the user-
>defined function that will take the value of "self". Or, perhaps, the
>inability to use one in a C extension. Maybe your original post spelled out
>some brilliantly deduced logical consequences of this apparently innocuous
>difference. If so, they slid right past me <wink>.


The consequence is I have to know the implementation of a callable object
in order to use it as a class variable.  It means I can't write a
drop-in replacement of one of my C libraries with an equivalent pure
Python module in the obvious way of implementing the C-based functions
using user-defined Python functions.  (I could do it by using a
singleton callable object.)

The only other place in Python that a use distinction arises between C
code and Python code is the type/class dichotomy, where you can't derive
from a type.  That's considered to be something which should be fixed,
and I feel this should as well.

Consider

class C:
  f = f

c = C()
print f(), c.f()

If this works, then f is not a user-defined function; it is either
implemented
in C or is a callable object.

On the other hand, if

print f(c), c.f()

works, then f is a user-defined function.  Ummm.. unless it takes *args,
but that's beside the point.

Now that I know it exists and works as documented, I'll live with it
and I'll change my code to work around it.

I still wanted to complain that it isn't obvious that that's the
appropriate behaviour, in the hopes that someone would tell me why it
make sense, or that someday (Py3K?) it will be fixed.

Also, I do realize it is a rare case where this will be a problem, so
I'll shut up now.

                    Andrew
                    dalke at acm.org