Python doesn't know class of function ? : class C:def f():pass; l=[f]; print C.l[0].im_class

[Robert]

Hello, its a problem which arised within my proprietary context test
system (i don't like the awkward stiff unittest). e.g.:

    def f():
        "test dummy"
        print dscore.cfg.url_categories
    runTests(f)
    class TG(TestGroup):
        contexts = [CtxRegistry]
        def testA(self):
            print "A"
        def testB(self):
            print "B"
        tests=[testA,testB,f]
    runTests( TG, [CtxGerman,CtxLocalCache] )

   
the TG member "tests=[testA,testB,f]"   defines (additional) embedded
tests in TG, and optionally also forces the execution order of
(autocollected) textXXXX methods of the own class. I want to script
such tests short and pythonic, thus mix functions, instance method,
unbound methods, static methods, groups, ... the test comiler is
supposed to smartly identifying everything and do whats needed on the
fly.

So, when iterating the list in my test compiler, i need to know if the
function is a simple function from outside or an own method or a
method of other class/instance or whatever in order to possibly
instantiate the right classes on the fly an call the right method,
etc. The are also many other reasons why it is interesting to know the
class of such method-functions.

What I do now is to check each thing in the list if it possibly
matches a method of the own class by comparing against
getattr&method.im_func==thing. Not very elegant.
And if the method-function is coming similarly but indirectly from
another class(es list) i have no chance at all to detect the class...

I think when python compiles the TG class, python should know that the
testA thing is in class TG namespace (and set something like im_class)
?
Strange that below example X.g yields an <unbound method>, but inside
namesspace (tests list) its a mere <function> with no indication of
class(es namespace). could a class indicator not be set similar like
func_globals !?

I think this is somewhat broken design in python classes in order to
optimize compilation speed or so. I think they did that 'economical
implementation' because of the same reason that causes the following
not to work:

>>> class YYY:
... 	print YYY
... 	
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "<interactive input>", line 2, in YYY
NameError: name 'YYY' is not defined

I remember i missed this capability often too. 

Is there a true reason not to know the class thing while its namespace
is set up?

I suppose it would be possible for the compiler to do a simple setting
of the empty YYY class object to the outside global namespace before
compiling the interior and maybe set also a local reflexive __class__
or so to the class namespace locals(). (garbage collection
inefficient?afraid of exceptions?its the same as with modules i think)
Thus it would be at least possible to ...

        tests=[TG.testA,TG.testB,f]

And also compiling an im_class for unbound methods during class
compiliation would also be no problem.
I think that would be more consistent than seeking for functions in in
the locals() at the end of class definition in order to make them
<unbound methods> later - and forget my lovely tests=[...] ... ?

Robert

"John Roth" <newsgroups at jhrothjr.com> wrote in message news:<105m7thjapekofd at news.supernews.com>...
> "Robert" <k.robert at gmx.de> wrote in message
> news:19804fd8.0403190226.4a060ed0 at posting.google.com...
> > Python doesn't know the class of a method when container not direct
> > class attribute:
> >
> > >>> class X:
> > ... def f():pass
> > ... g=f
> > ... l=[f]
> > ...
> > >>> X.g
>  <unbound method X.f>
> > >>> X.l[0]
>  <function f at 0x01A9E1F0>
> > >>> X.l[0].im_class
> > Traceback (most recent call last):
> >   File "<interactive input>", line 1, in ?
> > AttributeError: 'function' object has no attribute 'im_class'
> > >>>
> >
> >
> > why is l[0] a <function>. Any possibility to find the class of this
> > beast dynamically?
> 
> As Terry said, this is not possible because of the highly
> dynamic nature of Python.
> 
> If you'd tell us a bit about what you're trying to accomplish
> by relating functions to the class where they're defined, we
> might be able to suggest some other ways of approaching
> the problem.
> 
> John Roth
> >
> > Robert