Possible bug with wchar_t *, python (and directors?)

View: New views
2 Messages — Rating Filter:   Alert me  

Possible bug with wchar_t *, python (and directors?)

by Alan Woodland-5 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

I've been scratching my head over this one for quite a while. I've
managed to produce a minimal working example that I think illustrates
my problem.

It seems that when directors are enabled (at least I can't make an
example where it happens without having directors enabled) passing an
optional const wchar_t* to a function causes an exception to be raised
from python:

TypeError: bad argument type for built-in operation

In the application I'm working on the python interpreter is embedded,
and using PyRun_SimpleString() PyErr_Print() doesn't show a stack
trace at all. In the example attached to this email the traceback is:
Traceback (most recent call last):
  File "runme.py", line 49, in <module>
    callback = PyCallback().__disown__()
  File "runme.py", line 12, in __init__
    example.Callback.__init__(self)
  File "/home/ajw05/code/portculis/mwe/callback/example.py", line 68,
in __init__
    if self.__class__ == Callback:
TypeError: bad argument type for built-in operation

I've tried this with python2.5 and swig 1.3.36 as well as 1.3.40 and
the result is the same.

My example is based on the python/callback/ example. This problem only
happens when a string is passed to the optional parameter of
Caller::call, if we change line 40 it doesn't happen any more. Notice
in the stack trace I posted though that it points to line 49, which is
sometime after the call to Caller::call. Furthermore the problem does
not exhibit itself if we change whcar_t* to char* in example.h, or
when the string is omitted.

Have I just done something wrong here? Or is this actually a bug?

Thanks,
Alan

[example.cxx]

/* File : example.cxx */

#include "example.h"



[example.h]

/* File : example.h */

#include <cstdio>
#include <iostream>

class Callback {
public:
        virtual ~Callback() { std::cout << "Callback::~Callback()" << std:: endl; }
        virtual void run() { std::cout << "Callback::run()" << std::endl; }
};


class Caller {
private:
        Callback *_callback;
public:
        Caller(): _callback(0) {}
        ~Caller() { delCallback(); }
        void delCallback() { delete _callback; _callback = 0; }
        void setCallback(Callback *cb) { delCallback(); _callback = cb; }
        void call(const wchar_t *text=0) { if (_callback) _callback->run(); }
};




[runme.py]

# file: runme.py

# This file illustrates the cross language polymorphism using directors.

import example


# CEO class, which overrides Employee::getPosition().

class PyCallback(example.Callback):
        def __init__(self):
                example.Callback.__init__(self)
        def run(self):
                print "PyCallback.run()"

# Create an Caller instance

caller = example.Caller()

# Add a simple C++ callback (caller owns the callback, so
# we disown it first by clearing the .thisown flag).

print "Adding and calling a normal C++ callback"
print "----------------------------------------"

callback = example.Callback()
callback.thisown = 0
caller.setCallback(callback)
caller.call()
caller.delCallback();

print
print "Adding and calling a Python callback"
print "------------------------------------"

# Add a Python callback (caller owns the callback, so we
# disown it first by calling __disown__).

caller.setCallback(PyCallback().__disown__())
caller.call("Break me!")
caller.delCallback()

print
print "Adding and calling another Python callback"
print "------------------------------------------"

# Lets do the same but use the weak reference this time.

callback = PyCallback().__disown__()
caller.setCallback(callback)
caller.call()
caller.delCallback()

# All done.

print
print "python exit"



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

example.i (336 bytes) Download Attachment

Re: Possible bug with wchar_t *, python (and directors?)

by Alan Woodland-5 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

2009/10/22 Alan Woodland <alan.woodland@...>:

> Hi,
>
> I've been scratching my head over this one for quite a while. I've
> managed to produce a minimal working example that I think illustrates
> my problem.
>
> It seems that when directors are enabled (at least I can't make an
> example where it happens without having directors enabled) passing an
> optional const wchar_t* to a function causes an exception to be raised
> from python:
>
> TypeError: bad argument type for built-in operation
>
[snip]

> Have I just done something wrong here? Or is this actually a bug?
Ok, that was slightly dumb it would seem and my lack of python
knowledge has come back to byte ;)

Calling using u"My string" works, I was assuming python hid everything
like that from users. My question still sort of stands though:
1) Can I do anything with typemaps to make this automatic?
2) Why does the error not get raised until sometime after the string
was passed to C++? The C++ code actually looks like it worked
correctly, because the error didn't get raised until sometime later.
Can this be fixed in some way, so that either the C++ method doesn't
get called at all and for a TypeError gets raised at a more sensible
point?
3) Why did this not seem to be a problem for simple, single parameter
functions without directors enabled?

Thanks,
Alan

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user