def foo():
‘this is doc for foo’
print foo.__doc__

If __func__ will equal classname.funcname then it will not really be the function inside of which you are running. Example (using squigglies so tabbing dosn’ get messed up):
class a
{
def h(): pass
print id(h)
}
print id(h)

as you will see you get different values. (Look at type(a.h))

And if you do the function inside which you are really running then it is not the actual function that is getting called.

These same problems will exsist with decorators if they return new functions. So should __func__ refer to the new function or to the original one?

All of these can cause some very subtle bugs depending on how you are going to use it. Ok, if you use __doc__ then it works great, but how about if you are trying to access func_* and some decorator is actually implemented as a class (like instancemethod).

Anyway, it might SEEM simple but depending on what you are doing, this can lead to very subtle bugs.

import inspect

def getname():
“”"Here are the instructions of what input I expect
and of what the function does, two things in one, I am just lazy!
“”"
f = inspect.currentframe().f_code.co_name
print globals()[f].__doc__
inp = raw_input(’Please input here: ‘)
# Prepare input data …
return inp

It has to do with name binding, not entirely unlike the issue of lambdas in loops if I remember correctly.

As for __func__ for a method, I think it should return &;ltclass_name>.<method_name> to allow method unbinding (via staticmethod() decorator).

Sorry for the mess.

As for __func__ for a method, I think it should return . to allow method unbinding (via staticmethod() decorator).

Neither do I understand it. But I’d like to ask a question.

if __func__ refers to the function you’re in (as in def foo(): __func__ == foo)

what does __func__ in a class method refer to,

class bar:
def foo( self ): __func__ == bar.foo or __func__ == self.foo ?

and what is it in a generator
def foo(): yield __func__ == foo or __func__ == foo()?