Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Printing __doc__

2 views
Skip to first unread message

gtb

unread,
Mar 21, 2007, 3:47:06 PM3/21/07
to
Greetings,

Don't know the daily limit for dumb questions so I will ask one or
more.

In a function I can use the statement n =
sys._getframe().f_code.co_name to get the name of the current
function. Given that I can get the name how can I print the __doc__
string? I cant use the following, it will tell me to bugger off as the
string has no such attribute.

def spam(self):
n = sys._getframe().f_code.co_name
print n.__doc__ #Wrong
print __doc__ #No good either
#....


thanx,

gtb

Terry Reedy

unread,
Mar 21, 2007, 4:11:45 PM3/21/07
to pytho...@python.org

"gtb" <goodTwe...@hotmail.com> wrote in message
news:1174506426.1...@d57g2000hsg.googlegroups.com...

The docstring you are looking for is attached to the *function* object as
.__doc__ and .func_doc. Frame.f_code is a *code* object. It has a
boilerplate doc string, but not the one you want. As near as I can tell,
frames do not keep references to the func object but only the code object,
which is all it needs to run the code.

I believe tracebacks use co_filename and co_name to find the text of a
function. You could try to parse out the doc string from there.

Terry Jan Reedy

Peter Otten

unread,
Mar 21, 2007, 4:35:29 PM3/21/07
to
gtb wrote:

> In a function I can use the statement n =
> sys._getframe().f_code.co_name to get the name of the current
> function. Given that I can get the name how can I print the __doc__
> string? I cant use the following, it will tell me to bugger off as the
> string has no such attribute.
>
> def spam(self):
> n = sys._getframe().f_code.co_name
> print n.__doc__ #Wrong
> print __doc__ #No good either
> #....

>>> import sys
>>> def docstring():
... return sys._getframe(1).f_code.co_consts[0]
...
>>> def foo():
... print "My docstring is %r" % docstring()
...
>>> def bar():
... "bar's docstring"
... print "My docstring is %r" % docstring()
...
>>> foo()
My docstring is None
>>> bar()
My docstring is "bar's docstring"

No idea how brittle that might be, though.

Peter

gtb

unread,
Mar 21, 2007, 4:37:09 PM3/21/07
to
On Mar 21, 3:11 pm, "Terry Reedy" <tjre...@udel.edu> wrote:
> "gtb" <goodTweetieB...@hotmail.com> wrote in message

Thanks for posting.

OK, .__doc__ or .func_doc

But still the question remains. I cannot use
print .__doc__
OR
print .func_doc

within the function.


gtb

unread,
Mar 21, 2007, 4:52:56 PM3/21/07
to

Thanks.

Pardon my ignorance, but brittle?

Cameron Laird

unread,
Mar 21, 2007, 6:28:31 PM3/21/07
to
In article <1174510376.4...@e1g2000hsg.googlegroups.com>,

gtb <goodTwe...@hotmail.com> wrote:
>On Mar 21, 3:35 pm, Peter Otten <__pete...@web.de> wrote:
.
.

.
>> >>> import sys
>> >>> def docstring():
>>
>> ... return sys._getframe(1).f_code.co_consts[0]
>> ...>>> def foo():
>>
>> ... print "My docstring is %r" % docstring()
>> ...>>> def bar():
>>
>> ... "bar's docstring"
>> ... print "My docstring is %r" % docstring()
>> ...>>> foo()
>>
>> My docstring is None>>> bar()
>>
>> My docstring is "bar's docstring"
>>
>> No idea how brittle that might be, though.
>>
>> Peter
>
>Thanks.
>
>Pardon my ignorance, but brittle?
>

Peter is trying to communicate that some aspects of Python are
quite conservative, well-documented, and unlikely to change
across versions or implementations. The syntax of, let's say,
"def", is an example of such an aspect.

Peter has no particular evidence about the guarantees of the
sys._getframe(1).f_code.co_consts[0]
resolution; for all he or I know, the core Python maintainers
might change in an upcoming release the implementation of
co_consts. That's what I believe he intends you understand by
"brittle".

Terry Reedy

unread,
Mar 21, 2007, 7:30:00 PM3/21/07
to pytho...@python.org

"Cameron Laird" <cla...@lairds.us> wrote in message
news:f5o8d4-...@lairds.us...

|| Peter is trying to communicate that some aspects of Python are
| quite conservative, well-documented, and unlikely to change
| across versions or implementations. The syntax of, let's say,
| "def", is an example of such an aspect.
|
| Peter has no particular evidence about the guarantees of the
| sys._getframe(1).f_code.co_consts[0]
| resolution; for all he or I know, the core Python maintainers
| might change in an upcoming release the implementation of
| co_consts. That's what I believe he intends you understand by
| "brittle".

There is also no reason to expect that such code would work with Python
interpreters other than CPython.

tjr

Bart Ogryczak

unread,
Mar 22, 2007, 12:36:51 PM3/22/07
to

print eval(n+'.__doc__')


0 new messages