Prev: PDF Generation With Reportlab
Next: pysandbox 1.0: a new sandbox for Python
From: Chris Rebert on 28 Jun 2010 14:25
On Mon, Jun 28, 2010 at 11:13 AM, Brian Blais <bblais(a)bryant.edu> wrote:
> On Jun 27, 2010, at 22:37 , Red Forks wrote:
>> Read you doc file and set the __doc__ attr of the object you want to
>> change.
>>
>> On Monday, June 28, 2010, Brian Blais <bblais(a)bryant.edu> wrote:
>>> I know that the help text for an object will give a description of every
>>> method based on the doc string.  Is there a way to add something to this
>>> text, specific to an object, but generated at run-time?  I have an object
>>> that reads a file, and I would like part of that file to be shown if one
>>> does:  help(myobject)
>
> python file:
>
> #=============
> class A(object):
>    pass
>
> help_text="this is some text"
>
> a=A()
> a.__doc__=help_text
> #=============
>
> in ipython:
>
> shows up here:
>
> In [5]:a?
> Type:           A
> Base Class:     <class '__main__.A'>
> String Form:    <__main__.A object at 0x13270f0>
> Namespace:      Interactive
> File:
> /Library/Frameworks/Python.framework/Versions/5.0.0/lib/python2.5/site-packages/IPython/FakeModule.py
> Docstring:
>    this is some text
>
>
> but not with the help command:
>
> In [6]:help(a)
> Help on A in module __main__ object:
>
> class A(__builtin__.object)
>  |  Data descriptors defined here:
>  |
>  |  __dict__
>  |      dictionary for instance variables (if defined)
>  |
>  |  __weakref__
>  |      list of weak references to the object (if defined)
>
>
> also does the same thing with the regular python prompt.
>
> is there a reason for this?

__doc__ is normally defined on classes, e.g. `A`, not instances, e.g.
`a`. help() looks for __doc__ accordingly.

Cheers,
Chris
--
http://blog.rebertia.com
From: Benjamin Kaplan on 28 Jun 2010 15:02
On Mon, Jun 28, 2010 at 11:25 AM, Chris Rebert <clp2(a)rebertia.com> wrote:
> On Mon, Jun 28, 2010 at 11:13 AM, Brian Blais <bblais(a)bryant.edu> wrote:
>> On Jun 27, 2010, at 22:37 , Red Forks wrote:
>>> Read you doc file and set the __doc__ attr of the object you want to
>>> change.
>>>
>>> On Monday, June 28, 2010, Brian Blais <bblais(a)bryant.edu> wrote:
>>>> I know that the help text for an object will give a description of every
>>>> method based on the doc string.  Is there a way to add something to this
>>>> text, specific to an object, but generated at run-time?  I have an object
>>>> that reads a file, and I would like part of that file to be shown if one
>>>> does:  help(myobject)
>>
>> python file:
>>
>> #=============
>> class A(object):
>>    pass
>>
>> help_text="this is some text"
>>
>> a=A()
>> a.__doc__=help_text
>> #=============
>>
>> in ipython:
>>
>> shows up here:
>>
>> In [5]:a?
>> Type:           A
>> Base Class:     <class '__main__.A'>
>> String Form:    <__main__.A object at 0x13270f0>
>> Namespace:      Interactive
>> File:
>> /Library/Frameworks/Python.framework/Versions/5.0.0/lib/python2.5/site-packages/IPython/FakeModule.py
>> Docstring:
>>    this is some text
>>
>>
>> but not with the help command:
>>
>> In [6]:help(a)
>> Help on A in module __main__ object:
>>
>> class A(__builtin__.object)
>>  |  Data descriptors defined here:
>>  |
>>  |  __dict__
>>  |      dictionary for instance variables (if defined)
>>  |
>>  |  __weakref__
>>  |      list of weak references to the object (if defined)
>>
>>
>> also does the same thing with the regular python prompt.
>>
>> is there a reason for this?
>
> __doc__ is normally defined on classes, e.g. `A`, not instances, e.g.
> `a`. help() looks for __doc__ accordingly.
>
> Cheers,
> Chris
> --


Just to save the OP some trouble later on: this optimization is done
for most of the __*__ methods. Overriding __add__ on an instance won't
change the behavior of a + b.
From: Emile van Sebille on 28 Jun 2010 16:13
On 6/28/2010 12:02 PM Benjamin Kaplan said...
> Just to save the OP some trouble later on: this optimization is done
> for most of the __*__ methods. Overriding __add__ on an instance won't
> change the behavior of a + b.

ActivePython 2.4.1 Build 247 (ActiveState Corp.) based on
Python 2.4.1 (#65, Jun 20 2005, 17:01:55) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class Test: pass
....
>>> i = Test()
>>> i+1
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for +: 'instance' and 'int'
>>> def __add__(self): return 6
....
>>> i.__add__ = __add__
>>> i+1
6
>>>

Was this in reference to a specific python version?

Emile

From: Thomas Jollans on 28 Jun 2010 16:46
On 06/28/2010 10:13 PM, Emile van Sebille wrote:
> On 6/28/2010 12:02 PM Benjamin Kaplan said...
>> Just to save the OP some trouble later on: this optimization is done
>> for most of the __*__ methods. Overriding __add__ on an instance won't
>> change the behavior of a + b.
>
> ActivePython 2.4.1 Build 247 (ActiveState Corp.) based on
> Python 2.4.1 (#65, Jun 20 2005, 17:01:55) [MSC v.1310 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> class Test: pass
> ...
>>>> i = Test()
>>>> i+1
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> TypeError: unsupported operand type(s) for +: 'instance' and 'int'
>>>> def __add__(self): return 6
> ...
>>>> i.__add__ = __add__
>>>> i+1
> 6
>>>>
>
> Was this in reference to a specific python version?

ahem


Python 2.5.5 (r255:77872, Apr 21 2010, 08:40:04)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A(object):
.... def __add__(self, other):
.... return "indeed"
....
>>> a = A()
>>> a + 1
'indeed'
>>> def new__add__(other):
.... return "not at all"
....
>>> a.__add__ = new__add__
>>> a.__add__(1)
'not at all'
>>> a+1
'indeed'
>>>
>>>
>>> class B:
.... def __add__(self, other):
.... return 'now this is old-style'
....
>>> b = B()
>>> b+1
'now this is old-style'
>>> b.__add__ = new__add__
>>> b+1
'not at all'
>>>

I hate the fact that Python 2.x has two types of classes. Good riddance.

-- Thomas
From: Stephen Hansen on 28 Jun 2010 16:48
On 6/28/10 1:13 PM, Emile van Sebille wrote:
> On 6/28/2010 12:02 PM Benjamin Kaplan said...
>> Just to save the OP some trouble later on: this optimization is done
>> for most of the __*__ methods. Overriding __add__ on an instance won't
>> change the behavior of a + b.
>
> ActivePython 2.4.1 Build 247 (ActiveState Corp.) based on
> Python 2.4.1 (#65, Jun 20 2005, 17:01:55) [MSC v.1310 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> class Test: pass
> ...
> >>> i = Test()
> >>> i+1
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> TypeError: unsupported operand type(s) for +: 'instance' and 'int'
> >>> def __add__(self): return 6
> ...
> >>> i.__add__ = __add__
> >>> i+1
> 6
> >>>
>
> Was this in reference to a specific python version?

No, its a reference to new-style vs old-style classes. If Test inherits
from object, it won't work. Its one of several subtle behaviorial
differences between old/new classes.

--

... Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/

 |  Next  |  Last
Pages: 1 2
Prev: PDF Generation With Reportlab
Next: pysandbox 1.0: a new sandbox for Python