prints up the tool tip with an erroneous signature:
wx.ToolBar.AddLabelTool(self, id, label, bitmap, bmpDisabled=<wx._gdi.Bitmap; proxy of <Swig Object of type ‘wxBitmap *’ at 0x14974c8> >, kind=0, shortHelp=’’, longHelp=’’, clientData=None)
Note the "bmpDisabled=<wx._gdi.Bitmap; proxy of <Swig Object of type ‘wxBitmap *’ at 0x14974c8> >, "
That's because it is doing a runtime evaluation of the method and its default arg values instead of doing a static code analysis. That parameter's default value is wx.NullBitmap, and if you do a repr(wx.NullBitmap) you'll see the same value.
I'm not sure if Python's inspect module or wx.py's introspect module can be made to work differently without totally gutting wx.py, but if you look into it and can come up with a better way to fetch and display that signature (and others with the same issue) then I'll apply a patch.
···
On 6/1/12 6:39 AM, DevPlayer wrote:
While in PySlices:
typing
wx.ToolBar.AddLabelTool(
prints up the tool tip with an erroneous signature:
wx.ToolBar.AddLabelTool(self, id, label, bitmap,
bmpDisabled=<wx._gdi.Bitmap; proxy of <Swig Object of type 'wxBitmap *'
at 0x14974c8> >, kind=0, shortHelp='', longHelp='', clientData=None)
Note the "bmpDisabled=<wx._gdi.Bitmap; proxy of <Swig Object of type
'wxBitmap *' at 0x14974c8> >, "
wxPython '2.8.11.0 (msw-unicode)'
Python '2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)]'
I did not discover any preexisting tickets in trac for wxwidgets
searching with "wx.ToolBar.AddLabelTool" or "AddLabelTool"
I have not created a ticket.
Well, it being a tool tip for only wxPython coders and it not being a
end user issue at all, leaving it as it would make sense.
I did notice the _core.py has the function def __swig_repr() which
returns that nasty string. The only whacky idea I could think of is to
enchance that function to check if the C version of the object if it
had a yet-to-be-included-documentation attribute like _ _ _ repr__
(note 3 prefixed underscores) and let the __swig_repr() function
return something like "Null" + __class__.__name__ if hasattr(obj,
'___repr__') (note 3 prefixed underscores) instead of its natural
__repr__().
Also if I have not mistakenly thought, if a class' __init__() has a
triple quoted text block for it's __doc__ and the first line of that
text string was often used as a way of "documenting" the __init__()
function signature no? I thought I saw a few places in the code that
avoided the nasty tooltip text by doing just that.
If reading that idea about adding a new special attribute to the C
language widget definition made your eye's bleed; perhaps make just
one eye bleed and add a new special attribute to the python coded
version for documentation?? (Without justification, for some reason,
that seems distasteful to me) Or perhaps that gives you readers a
different -good- idea.
And if the sight of blood on your eyes makes you faint; then keep to
using the widgets __init__ standard docstring practice.
These idea's may be bad (or perhaps one day I'll get lucky and stumble
upon a good idea) but they are offered for consideration in the spirit
of trying to make things easier to maintain. I'll let the experts take
it or leave it.
If the tooltip text is infact generated by some __repr__ method, and since
Pheonix is moving to Python 3, then this may be of interest: What’s New In Python 3.2 — Python 3.14.0a1 documentation
Scroll down to reprlib which talks about recursive __repr__ calls.
there is no need for all this repr-voodoo stuff (which, reading from
the whatsnew documentation, a very narrow corner-case) for Phoenix.
See here:
For the default signature of AddLabelTool. All the runtime evaluation
of instantiated classes (or whatever their proper name is) is now
overridden by the Phoenix documentation builder, and it knows what to
evaluate and what not to evaluate (in order to avoid funny default
arguments like "<wx._gdi.Bitmap; proxy of <Swig Object of type
'wxBitmap *' at 0x14974c8>"). It will work on the Phoenix core as well
as on wx.lib and its sub-packages.