User Access to the docstring of a property

[Colin J. Williams]

Is there some way that the user can access the docstring specified for a
property?

Please see the example below:

# propDocTest
class A(object):
def __init__(self, value):
self.value= value
def vGet(self):
return self.value
V= property (fget= vGet, doc="Get Value.")

a= A(22)
print a.vGet()
print a.V
print a.V.__doc__ # this gives the docstring for the value returned
help(a.V) # this gives the docstring for the class/type of
the value returned

Colin W.

 

[Diez B. Roggisch]

Is there some way that the user can access the docstring specified for a
property?

You need to access it using the class, not an instance of it.

class Foo(object):

@apply
def prop():
def fget(self):
return 10
def fset(self, value):
pass
doc = "this is a docstring"
return property(**locals())

f = Foo()
print f.prop


print Foo.prop.__doc__

print f.__class__.prop.__doc__


Diez

 

[georgeryoung]

Is there some way that the user can access the docstring specified for a
property?

Do keep in mind that the docstring is not guaranteed to be available.
If
the application is run with optimization turned on, docstrings are
usually
optimized out. Docstrings are handy for reading code and maybe for
debugging, but should not be relied upon for "users", as opposed to
developers.

-- George Young

 

[Colin J. Williams]

George,

Thanks to Dietz and yourself.

Yes, I should have referenced the class, rather than the instance.
However, for methods, the docstring is revealed for an instance.

Colin W.

PS It would help if someone could explain the use of @apply in the
example Dietz gave. The documentation gives no reference to @ or to
decorators.

 

[Diez B. Roggisch]

George,

Thanks to Dietz and yourself.

Yes, I should have referenced the class, rather than the instance.
However, for methods, the docstring is revealed for an instance.

Colin W.

PS It would help if someone could explain the use of @apply in the
example Dietz gave. The documentation gives no reference to @ or to

The decorator semantics are simple:


@a
@b(argument)
def foo():
pass

get translated to

foo = a(b(argument)(foo))

as a decorator is nothing but function that is called with one thing,
and returns something else. or the same thing, by the way.

Now apply was important back then before the *args and **keywordargs
shortcuts where introduced.

It basically takes a function as first argument, and possibly a list
and/or dict, and invokes the function with that argumens in place.

So

def foo(a):
print a

apply(foo, [10])

works as simple as

foo(10)


locals() is a built-in that returns a dictionary which contains all the
locally known names.

And property is a descriptor-creation-function, that has this signature:

property(fget, fset, fdel, doc)

Now we have all we need to decompose that neat property-creation-trick
that doesn't pollute the class' namespace:

class Foo(object):
@apply
def bar():
def fget(self):
return self._bar
doc = "bar property"
return property(**locals())



What happens is this:

the decoration gets translated to this:

bar = apply(bar)

which does simply invoke bar, and assign the result to the name bar in
the class.

invoking bar executes the property function, which is fed with the
dictionary of the locals - coincidently named after the named arguments
property takes.


What I really do love about this: it doesn't pollute the namespace.

Regards,

Diez