From: Bo P. <be...@gm...> - 2007-04-13 03:01:12
|
Dear list, I define %docstring for all class member functions, in my swig generated python file, I have a class like class myclass(baseclass): """ Description of the class """ thisown = _swig_property(lambda x: x.this.own(), lambda x, v: x.this.own(v), doc='The membership flag') def __init__(self, *args): """ Description of init """ _mymodule.myclass_swiginit(self,_mymodule.new_myclass(*args)) def memberfunc(*args, **kwargs): """ Description of memberfunc """ return _mymodule.myclass_memberfunc(*args, **kwargs) However, in python, help(myclass.memberfunc) gives me myclass_memberfunc(...) unbound mymodule.myclass method. Why is this happening? How can I set docstring for member functions? Many thanks in advance. Cheers, Bo |
From: Bo P. <be...@gm...> - 2007-04-13 20:39:34
|
> > Why is this happening? How can I set docstring for member functions? The problem is with a later line: myclass.memberfunc = new_instancemethod(_mymodule.myclass_memberfunc,None,myclass) which overrides the previous regular definition with __doc__. If I remove this line, the member function seems to work, and __doc__ would appear. Why do we have myclass.memberfunc defined in myclass, and using new_instancemethod again? Is there a way to regain my docstring? Many thanks in advance. Cheers, Bo |
From: Richard B. <ri...@le...> - 2007-04-13 23:09:09
|
Bo Peng wrote: >> Why is this happening? How can I set docstring for member functions? > > The problem is with a later line: > > myclass.memberfunc = > new_instancemethod(_mymodule.myclass_memberfunc,None,myclass) > > which overrides the previous regular definition with __doc__. > > If I remove this line, the member function seems to work, and __doc__ > would appear. Why do we have myclass.memberfunc defined in myclass, > and using new_instancemethod again? Is there a way to regain my > docstring? I noticed this problem myself, independently, earlier today, and have put a patch together which adds the docstring to the builtin function passed to new_instancemethod, making it visible again. The patch is in the issue tracker, so hopefully someone with permissions will apply it at some point - if you don't want to wait for that, you could check swig out from SVN and apply the patch. The patch is available at: http://sf.net/tracker/index.php?func=detail&aid=1700146&group_id=1645&atid=301645 It might be nice if swig didn't duplicate the comment (and indeed, the method definition) in this situation, but I'm not familiar enough with the code to know if there is some hidden reason that this isn't a good idea. Out of interest - are you running swig with the -O flag? I've only observed this problem happening if I do that: one of the optimisations it turns on is a "fastproxy" feature, which is what generates the line you found causing the problem - I don't know why this line would be faster, but I assume it is (otherwise it's odd that someone implemented it). You can probably work around the problem by not supplying -O to swig until this is patched. -- Richard |
From: Bo P. <be...@gm...> - 2007-04-14 02:00:03
|
> You can probably work around the problem by not supplying -O to > swig until this is patched. I remove the -O option and the help messages are back. I will add this option later after your patch is applied. Thank you very much for your help. Bo |
From: Bo P. <be...@gm...> - 2007-04-19 18:56:53
|
> I noticed this problem myself, independently, earlier today, and have > put a patch together which adds the docstring to the builtin function > passed to new_instancemethod, making it visible again. The patch is in > the issue tracker, so hopefully someone with permissions will apply it > at some point - if you don't want to wait for that, you could check swig > out from SVN and apply the patch. The patch is available at: > http://sf.net/tracker/index.php?func=detail&aid=1700146&group_id=1645&atid=301645 I can confirm that this patch works. Cheers, Bo |
From: Olly B. <ol...@su...> - 2007-04-20 01:18:17
|
On 2007-04-19, Bo Peng <be...@gm...> wrote: >> http://sf.net/tracker/index.php?func=detail&aid=1700146&group_id=1645&atid=301645 > > I can confirm that this patch works. Thanks for the confirmation. I've now applied Richard's patch to SVN HEAD, so this should be fixed in the next release of SWIG. Cheers, Olly |
From: Bo P. <be...@gm...> - 2007-05-21 14:58:39
|
> Thanks for the confirmation. I've now applied Richard's patch to SVN > HEAD, so this should be fixed in the next release of SWIG. I have a problem with this patch. Using a previous version, the following code in the wrap file always have NULL as the last field, and now it can have a really long string. static PyMethodDef SwigMethods[] = { <many more lines> { (char *)"GenoStruTrait_numLoci", _wrap_GenoStruTrait_numLoci, METH_VARARGS, (char *)"LONG STRING"}, } In my case, Visual C++ reports c2026 error due to excessive long string, while g++ works fine. I seems that breaking "LONG STRING" to "LONG " "STRING" can fix this problem, but I am not sure if this is something SWIG should do. Thanks. Bo |
From: Bo P. <be...@gm...> - 2007-05-28 02:59:30
Attachments:
bug_report.i
|
> Working out how to fix this isn't too hard, but without a testcase I > can't test my fix actually works. Can you provide a self-contained > example which currently fails for you? Attached please find a test interface file with commands listed at the end. I generate the wrap file under linux and try to compile the .cxx file under windows because I do not have swig/svn under windows. Thanks. Bo |
From: Olly B. <ol...@su...> - 2007-05-29 01:00:34
|
On Sun, May 27, 2007 at 09:59:27PM -0500, Bo Peng wrote: > Attached please find a test interface file with commands listed at the > end. I generate the wrap file under linux and try to compile the .cxx > file under windows because I do not have swig/svn under windows. Thanks - I've just committed a fix to SVN. I'm unable to actually test compilation with MSVC, but the generated source code no longer contains such long literal strings so it should be happy now. Cheers, Olly |
From: Bo P. <be...@gm...> - 2007-05-29 04:08:03
|
> Thanks - I've just committed a fix to SVN. I'm unable to actually test > compilation with MSVC, but the generated source code no longer contains > such long literal strings so it should be happy now. I have just tried the current svn, and MSVC stops complaining about the generated wrap file. Thanks. Bo |
From: Richard B. <ri...@le...> - 2007-05-21 15:12:05
|
Bo Peng wrote: >> Thanks for the confirmation. I've now applied Richard's patch to SVN >> HEAD, so this should be fixed in the next release of SWIG. > > I have a problem with this patch. Using a previous version, the > following code in the wrap file always have NULL as the last field, > and now it can have a really long string. True. > static PyMethodDef SwigMethods[] = { > <many more lines> > { (char *)"GenoStruTrait_numLoci", _wrap_GenoStruTrait_numLoci, > METH_VARARGS, (char *)"LONG STRING"}, > } Where I assume "LONG STRING" represents a different long string. > In my case, Visual C++ reports c2026 error due to excessive long > string, while g++ works fine. I seems that breaking "LONG STRING" to > "LONG " "STRING" can fix this problem, but I am not sure if this is > something SWIG should do. It seems reasonable to me that SWIG should try to generate code that works for common compilers. Splitting strings like this shouldn't affect the validity of the code, I think, so wouldn't be unreasonable if it fixes the problem. Which version of Visual C++ have you seen this problem in, and how long does the string have to be before it's triggered? Some of the strings in the Xapian Python bindings are quite long, but we've compiled with Visual C++ successfully - I wonder if our strings are just short enough, or if compilation will be broken with other versions of Visual C++. I believe we've been testing with Visual C++ 2005, but I'm not an MS user and I'm not certain of that. -- Richard |
From: Bo P. <be...@gm...> - 2007-05-21 19:53:53
|
> Which version of Visual C++ have you seen this problem in, and how long > does the string have to be before it's triggered? I am using the 'standard' MSVC version for python extensions, e.g. Visual Studio .NET 2003. > Some of the strings > in the Xapian Python bindings are quite long, but we've compiled with > Visual C++ successfully - I wonder if our strings are just short enough, This happens to a constructor with > 20 parameters and its __doc__ exceeds 5000 characters. According to http://msdn2.microsoft.com/en-us/library/dddywwsc(vs.71).aspx , this should be limited to 2048 single-byte characters. The "LONG" "STRING" solution is suggested on that page, but I have never tried. Thanks. Bo |
From: Olly B. <ol...@su...> - 2007-05-22 08:05:54
|
On 2007-05-21, Bo Peng <be...@gm...> wrote: > This happens to a constructor with > 20 parameters and its __doc__ > exceeds 5000 characters. According to > http://msdn2.microsoft.com/en-us/library/dddywwsc(vs.71).aspx , this > should be limited to 2048 single-byte characters. > > The "LONG" "STRING" solution is suggested on that page, but I have > never tried. Can you try it to verify it works? If it does, it's a reasonable workaround. However, it seems odd that a compiler would impose a 2048 byte limit before concatenation, but happily handle longer literals afterwards, so I'd like confirmation that this actually works. If you can supply a patch against SWIG itself, that would be even better! Cheers, Olly |
From: Bo P. <be...@gm...> - 2007-05-22 19:07:26
|
On 5/22/07, Olly Betts <ol...@su...> wrote: > On 2007-05-21, Bo Peng <be...@gm...> wrote: > > This happens to a constructor with > 20 parameters and its __doc__ > > exceeds 5000 characters. According to > > http://msdn2.microsoft.com/en-us/library/dddywwsc(vs.71).aspx , this > > should be limited to 2048 single-byte characters. > > > > The "LONG" "STRING" solution is suggested on that page, but I have > > never tried. > > Can you try it to verify it works? I can confirm it works. > If you can supply a patch against SWIG itself, that would be even > better! Basically, ds at line 1426 and 1434 of Modules/python.cxx need to insert a \" \" at every 2048 characters. Something like String ds1; for(size_t i=0; i < ds.size(); i *= 80) ds1 += ds[i, min((i+1)*80, ds.size))] + "\"\n \""; ds = ds1; I use 80 and \n to make _wrap file a bit more readable. I had a look at DOHString and could not find a convenient way to do it. Sorry. Cheers, Bo |
From: Olly B. <ol...@su...> - 2007-05-27 16:43:18
|
On 2007-05-22, Bo Peng <be...@gm...> wrote: > On 5/22/07, Olly Betts <ol...@su...> wrote: >> If you can supply a patch against SWIG itself, that would be even >> better! > > Basically, ds at line 1426 and 1434 of Modules/python.cxx need to > insert a \" \" at every 2048 characters. Something like A (slightly flawed) description of the changes required isn't a patch! Working out how to fix this isn't too hard, but without a testcase I can't test my fix actually works. Can you provide a self-contained example which currently fails for you? Cheers, Olly |