(0002783)
Lydia Ng (developer)
2005-08-05 15:26

Triaged 8/5/05 tcon. Assigned to Brad.

(0002795)
Brad King (manager)
2005-08-05 16:40

ITK's wrapping process uses SWIG. It looks like this bug is inherited from that project. The following message from the SWIG mailing list explains it:

http://mailman.cs.uchicago.edu/pipermail/swig/2004-October/010716.html [^]

Josh Cherry jcherry@ncbi.nlm.nih.gov
Mon, 18 Oct 2004 15:16:37 -0400 (EDT)

    * Previous message: [Swig] SWIG sets non-string key in __dict__?
    * Next message: [Swig] Help needed please
    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Mon, 18 Oct 2004, Skip Montanaro wrote:

>
> I've noticed that SWIG seems to set values in a Python wrapper object's
> __dict__ using non-string keys. If obj is a SWIG-generated instance,
> something like
>
> print [k for k in dir(obj) if k.startswith("set_")]
>
> fails because one of the k's isn't a string or unicode object. Sure enough,
> looking at a simple dir() of a SWIG-generated object shows things like:
>
> ['__class__', '__del__', '__delattr__', '__dict__', '__doc__',
> '__getattr__', '__getattribute__', '__hash__', '__init__', '__module__',
> '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__',
> '__str__', '__swig_getmethods__', '__swig_setmethods__', '__weakref__',
> 'context', 'instance', 'signal_timer', 'this', 'thisown',
> <class 'tradelink.glibEventLoop.v4_1.glibEventLoop.EventLoopPtr'>]
>
> (Note the last item in the list.)
>
> We're using SWIG 1.3.21, just one micro release older than the latest, so I
> suspect we're not "too old". Is this an ugly hack or a SWIG bug?

I pointed this out a while ago; see
http://mailman.cs.uchicago.edu/pipermail/swig/2004-January/008907.html. [^] I
don't know whether it's been fixed in 1.3.22, but using the -modern switch
should solve the problem.

Josh

--
Joshua L. Cherry, Ph.D.
NCBI/NLM/NIH (Contractor)
jcherry@ncbi.nlm.nih.gov

(0009117)
Luis Ibanez (manager)
2007-09-19 10:23

Luis will verify the current version of SWIG.

(0022878)
Cory W Quammen (developer)
2010-11-04 22:48

Assumed fixed. If not, will reopen.

Issue History
Date Modified	Username	Field	Change
2007-09-19 10:23	Luis Ibanez	Assigned To	Brad King => Luis Ibanez
2007-09-19 10:23	Luis Ibanez	Note Added: 0009117
2007-09-21 15:57	Luis Ibanez	Relationship added	related to 0002095
2010-11-04 22:48	Cory W Quammen	Sprint Status	=> completed
2010-11-04 22:48	Cory W Quammen	Note Added: 0022878
2010-11-04 22:48	Cory W Quammen	Status	assigned => closed
2010-11-04 22:48	Cory W Quammen	Resolution	open => fixed

Notes
(0002783) Lydia Ng (developer) 2005-08-05 15:26	Triaged 8/5/05 tcon. Assigned to Brad.

(0002795) Brad King (manager) 2005-08-05 16:40	ITK's wrapping process uses SWIG. It looks like this bug is inherited from that project. The following message from the SWIG mailing list explains it: http://mailman.cs.uchicago.edu/pipermail/swig/2004-October/010716.html [^] Josh Cherry jcherry@ncbi.nlm.nih.gov Mon, 18 Oct 2004 15:16:37 -0400 (EDT) * Previous message: [Swig] SWIG sets non-string key in __dict__? * Next message: [Swig] Help needed please * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On Mon, 18 Oct 2004, Skip Montanaro wrote: > > I've noticed that SWIG seems to set values in a Python wrapper object's > __dict__ using non-string keys. If obj is a SWIG-generated instance, > something like > > print [k for k in dir(obj) if k.startswith("set_")] > > fails because one of the k's isn't a string or unicode object. Sure enough, > looking at a simple dir() of a SWIG-generated object shows things like: > > ['__class__', '__del__', '__delattr__', '__dict__', '__doc__', > '__getattr__', '__getattribute__', '__hash__', '__init__', '__module__', > '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', > '__str__', '__swig_getmethods__', '__swig_setmethods__', '__weakref__', > 'context', 'instance', 'signal_timer', 'this', 'thisown', > <class 'tradelink.glibEventLoop.v4_1.glibEventLoop.EventLoopPtr'>] > > (Note the last item in the list.) > > We're using SWIG 1.3.21, just one micro release older than the latest, so I > suspect we're not "too old". Is this an ugly hack or a SWIG bug? I pointed this out a while ago; see http://mailman.cs.uchicago.edu/pipermail/swig/2004-January/008907.html. [^] I don't know whether it's been fixed in 1.3.22, but using the -modern switch should solve the problem. Josh -- Joshua L. Cherry, Ph.D. NCBI/NLM/NIH (Contractor) jcherry@ncbi.nlm.nih.gov

(0009117) Luis Ibanez (manager) 2007-09-19 10:23	Luis will verify the current version of SWIG.

(0022878) Cory W Quammen (developer) 2010-11-04 22:48	Assumed fixed. If not, will reopen.