Hi Steve,
> > * built-in class function ignoring the property getter (some_func.__doc__
> > set to a property returns the property instead of invoking the getter)
>
> Not just functions, it is all instances. Properties are only invoked if
> they are on the class object, not the instance.
>
I see.
On Sun, Oct 07, 2018 at 06:17:47PM +0200, Marko Ristin-Kaufmann wrote:
> Hi,
> @Jonathan: thanks! I'll have a look at your links.
>
> So there are actually two issues if I understand correctly:
> * help() ignoring the property getter when invoked on an instance
Not just the property getter, but i
Hi,
@Jonathan: thanks! I'll have a look at your links.
So there are actually two issues if I understand correctly:
* help() ignoring the property getter when invoked on an instance
* built-in class function ignoring the property getter (some_func.__doc__
set to a property returns the property inst
Hi Marko
You wrote:
> I just couldn't figure out how to make the __doc__ attribute of a function a
> getter. Is this a bug or am I making a mistake? If it's my mistake, is there
> any other way how to dynamically __doc__ a function or am I forced to set
> __doc__ of a function at the decoratio
On Mon, Oct 8, 2018 at 2:14 AM Steven D'Aprano wrote:
> That might work for Marko's use-case, but the problem is more general
> and I'd like to consider the broader picture. Currently instance __doc__
> attributes are sometimes ignored by help(). Given these:
>
> py> class X:
> ... pass
> ...
On Mon, Oct 08, 2018 at 01:45:01AM +1100, Chris Angelico wrote:
> On Mon, Oct 8, 2018 at 1:41 AM Marko Ristin-Kaufmann
> wrote:
> > (If you wonder about the use case: I'd like to dynamically generate the
> > docstrings when functions are decorated with contracts from icontract
> > library. Condi
On Mon, Oct 8, 2018 at 1:56 AM Marko Ristin-Kaufmann
wrote:
>
> Hi Crhis,
>
>> Have you tried just generating the docstrings at decoration time and
>> applying them? By the sound of it, they won't change after that, and
>> the only reason to run it later is performance... but have you
>> actually
Hi Crhis,
Have you tried just generating the docstrings at decoration time and
> applying them? By the sound of it, they won't change after that, and
> the only reason to run it later is performance... but have you
> actually measured a performance hit resulting from that?
I did. On my laptop (I
On Mon, Oct 8, 2018 at 1:41 AM Marko Ristin-Kaufmann
wrote:
> (If you wonder about the use case: I'd like to dynamically generate the
> docstrings when functions are decorated with contracts from icontract
> library. Condition functions need to be parsed and re-formatted, so this is
> something
Hi Steve,
Here are a couple of code snippets. I hope it's not too verbose :)
Setting property on the __doc__ works on the instance, but not on the class:
class A:
@property
def __doc__(self):
return "Works only on the instance"
a = A()
print('A.__doc__ is {}'.format(A.__doc__))
On Sun, Oct 07, 2018 at 09:25:13AM +0200, Marko Ristin-Kaufmann wrote:
> Hi,
> I'm working on decorators that have a dynamic __doc__ property computed at
> runtime and not at decoration time.
You mean like this?
py> class X:
... @property
... def __doc__(self):
... return "NOBODY
Hi,
I'm working on decorators that have a dynamic __doc__ property computed at
runtime and not at decoration time.
The decorator must return the wrapper as a function and can not return a
callable object with __call__ since the "self" argument would not be
properly passed through the decorator. (M
12 matches
Mail list logo
