[Boost 1.29, python 2.2.2, g++ 3.2, RH8.0] I've been trying to get a Numeric array object passed in as an argument to a function I've defined in a BPLv2 module, without much success. At the moment I'm happy to get the object in as a PyArrayObject *, because I've got a bunch of code that is expecting those pointers. Since I can't figure out how to extract a PyArrayObject * from a python::numeric::array (if that's even possible), I've attempted to define the following simple function: PyObject *MatFunc(PyArrayObject *arg){ PyObject *res = PyTuple_New(2); return res; } (eventually this will do more, I'm starting small) but whenever I call this Python with a Numeric array as an argument, I get the dreaded catch-all "TypeError: bad argument type for built-in operation". Am I wrong to be even attempting this? Should I just give up and do a normal extension module? -greg ---- greg Landrum (greglandrum@earthlink.net) Software Carpenter/Computational Chemist
Sorry about that dumb question. I was experiencing a major brainlock. using python::numeric::array and the ptr() method appears to solve my problems. -greg
greg Landrum <greglandrum@mindspring.com> writes:
Sorry about that dumb question. I was experiencing a major brainlock.
using python::numeric::array and the ptr() method appears to solve my problems.
Great! When you're done, if you'd like to contribute an example for the tutorial or examples folder, that'd be super. -Dave -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Hi all, I followed a thread entitled "Python + Boost Python V2 + downcasting" from the start of November this year. I have a similar problem and am wondering what the final solution was and whether it has been incorporated into boost.python yet. To save you all running to archives, the original post from Nicolas Lelong follows. Cheers, Dan ------------------ SNIP ------------------------------------------- Hello, I'm experiencing some embedding+extending with BPLv2 - and I could not = find any answer to this simple question : I have, say, a c++ class 'Base' and a c++ class 'Derived': class Base { public: virtual int do_stuff() { return 0; } }; class Derived { public: virtual int do_more() { return 100; } }; class ObjectServer { public: Base* getObject(unsigned id) { return m_objects[id]; } Base* m_objects[12]; } declared in my module like this: class_<Base>("Base") .def("do_stuff", &Base::do_stuff); class_<Derived, bases<Base> >("Derived") .def("do_more", &Derived::do_more); class_<ObjectServer>("ObjectServer") .def("getObject", &ObjectServer::getObject, = return_internal_reference<>()); everything works fine - except that I can't get python to see the _real_ = class of the objects returned by getObject. I tried the following: ... obj =3D objectServer.getObject(0) print isinstance(obj, Base) print isinstance(obj, Derived) print issubclass(Derived, Base) print obj.__class__ and I get, when 'obj' is really a 'Derived*' ... 1 0 1 module.Base how can I get to know that an object is an instance of Derived ?! is = there a builtin way in Python ? a BPL v2 way ? I even thought about = implementing my own 'isinstance' function but I'm not familiar enough = with boost python & python !!... Any help or advice will be _greatly_ = appreciated :) Thanks in advance, Nicolas. ------------------ SNIP -------------------------------------------
"Daniel Paull" <dlp@fractaltechnologies.com> writes:
Hi all,
I followed a thread entitled "Python + Boost Python V2 + downcasting" from the start of November this year. I have a similar problem and am wondering what the final solution was and whether it has been incorporated into boost.python yet.
Well, I said I was going to do something about it, but then never actually did ;-) I'll see if I can whip something together. In the meantime, here's a question I'd like you and Nicolas to try to answer. Suppose I have: struct A { virtual ~A(); }; struct B : A {}; struct C : B {}; A* factory(int x) { return x == 0 ? new A : x == 1 ? new B : new C; } and #include <boost/python.hpp> using namespace boost::python; BOOST_PYTHON_MODULE(test) { def("factory", factory, return_value_policy<manage_new_object>()); class_<A>("A"); class_<B, bases<B> >("B"); // note, C not registered. } Now, clearly: >>> from test import * >>> type(factory(0)) test.A And, after my changes: >>> type(factory(1)) test.B But, what's the result of: >>> type(factory(2)) ?? It's easy enough to acheive "test.A". If you want it to be "test.B", my job is harder. It's easy enough to say "just find the most-derived type which is registered". But even in a single-inheritance hierarchy, that is not easy to do efficiently. Furthermore, C++ inheritance hierarchies in general form a DAG. If the actual type of the object isn't registered, there may not be any single most-derived type which is registered: A / \ B C <= B and C are registered \ / D <= D is not. So, what about cases like this one? -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Hi Dave,
Well, I said I was going to do something about it, but then never actually did ;-)
Happens to be best of us :)
struct A { virtual ~A(); }; struct B : A {}; struct C : B {};
A* factory(int x) { return x == 0 ? new A : x == 1 ? new B : new
C; }
and
#include <boost/python.hpp> using namespace boost::python; BOOST_PYTHON_MODULE(test) { def("factory", factory,
return_value_policy<manage_new_object>());
class_<A>("A"); class_<B, bases<B> >("B"); // note, C not registered. }
Now, clearly:
>>> from test import * >>> type(factory(0)) test.A
And, after my changes:
>>> type(factory(1)) test.B
But, what's the result of:
>>> type(factory(2))
I think that this should fall back to returning "A" for simplicities sake. Alternatively, you could (optionally) make this an error condition. That way you won't get any surprises if you're expecting all derived objects to be convertible to Python. What about cross module support - I assume (fingers crossed) it will work automatically. In the case above, "A" might be defined in one module, but "B" is defined in a completely different module. Would the downcast still succeed? (assuming both modules are imported in python)
Furthermore, C++ inheritance hierarchies in general form a DAG. If the actual type of the object isn't registered, there may not be any single most-derived type which is registered:
A / \ B C <= B and C are registered \ / D <= D is not.
So, what about cases like this one?
If you try to convert "D*" to python, you'd get a wrapped up "A*", just like before. The ambiguous case above sets a precedent for which downcasts can be performed automatically. I'll quote the online tutorial: Remember the Zen, Luke: "Explicit is better than implicit" "In the face of ambiguity, refuse the temptation to guess" Given this, I think that a sensible set of caveats on the use of automatic downcasts can be formed. Looking back at the DAG and keeping with this philosophy, I think you have to take the approach that and instance of "D" returned as an "A*" must: 1) be converted to a wrapped "D*" 2) if (1) fails (eg, D is not registered), either return a wrapped "A*", or, 3) signal an error. This sort of scheme would be perfect for my needs. Cheers, Dan
"Daniel Paull" <dlp@fractaltechnologies.com> writes:
But, what's the result of:
>>> type(factory(2))
I think that this should fall back to returning "A" for simplicities sake.
Works for me.
Alternatively, you could (optionally) make this an error condition. That way you won't get any surprises if you're expecting all derived objects to be convertible to Python.
I think that would be bad. Abstract factories where the derived classes don't add any interface are a common idiom.
What about cross module support - I assume (fingers crossed) it will work automatically.
Yes, I think we can arrange that.
In the case above, "A" might be defined in one module, but "B" is defined in a completely different module. Would the downcast still succeed? (assuming both modules are imported in python)
I believe you can already pass the Python 'A' instance containing a B* to a function accepting a B* or B& parameter, even if A and B are defined in separate modules... so, I guess the answer is yes.
Furthermore, C++ inheritance hierarchies in general form a DAG. If the actual type of the object isn't registered, there may not be any single most-derived type which is registered:
A / \ B C <= B and C are registered \ / D <= D is not.
So, what about cases like this one?
If you try to convert "D*" to python, you'd get a wrapped up "A*", just like before.
Hmm, no... If you convert D* to python, you get a Python 'D' object. You wouldn't be able to convert a D* to python unless D were registered. The question is, what happens when you convert an A* which points to a D object to python?
The ambiguous case above sets a precedent for which downcasts can be performed automatically. I'll quote the online tutorial:
Remember the Zen, Luke:
"Explicit is better than implicit" "In the face of ambiguity, refuse the temptation to guess"
That's a quote from the Zen of Python, by Tim Peters.
Given this, I think that a sensible set of caveats on the use of automatic downcasts can be formed.
Looking back at the DAG and keeping with this philosophy, I think you have to take the approach that and instance of "D" returned as an "A*" must:
1) be converted to a wrapped "D*" 2) if (1) fails (eg, D is not registered), either return a wrapped "A*", or, 3) signal an error.
This sort of scheme would be perfect for my needs.
OK, then. It'll have to be #2 or we'll kill abstract factories, and nobody wants that ;-) -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Furthermore, C++ inheritance hierarchies in general form a DAG. If the actual type of the object isn't registered, there may not be any single most-derived type which is registered:
A / \ B C <= B and C are registered \ / D <= D is not.
So, what about cases like this one?
If you try to convert "D*" to python, you'd get a wrapped up "A*", just like before.
Hmm, no...
If you convert D* to python, you get a Python 'D' object. You wouldn't be able to convert a D* to python unless D were registered. The question is, what happens when you convert an A* which points to a D object to python?
Sorry, I meant to state that if you pass a "D" object as an "A*" to python, you should get an "A" object in python if D is not registered. I think we all agree on this behaviour :)
Given this, I think that a sensible set of caveats on the use of automatic downcasts can be formed.
Looking back at the DAG and keeping with this philosophy, I think you have to take the approach that and instance of "D" returned as an "A*" must:
1) be converted to a wrapped "D*" 2) if (1) fails (eg, D is not registered), either return a wrapped "A*", or, 3) signal an error.
This sort of scheme would be perfect for my needs.
OK, then. It'll have to be #2 or we'll kill abstract factories, and nobody wants that ;-)
Sure, #2 will get me moving nicely. I had imagined #3 being optional, say, by a different return value policy or something similar. In retrospect, it is hardly an issue for boost.python as the result of the conversion can be asserted on the python side if the behaviour of #3 is really needed... I agree, only support #2. Cheers, Dan
Hi, I catch up late as you had this like exchange as I was sleeping :) All I can do is agree with everything you both came along ! I did not have time to complete the draft implementation I started in November but I'm still willing to lend a hand [if needed] as this subject is still of great relevance to me. Cheers, Nicolas.
"Nicolas Lelong" <n_lelong@hotmail.com> writes:
Hi,
I catch up late as you had this like exchange as I was sleeping :) All I can do is agree with everything you both came along !
I did not have time to complete the draft implementation I started in November but I'm still willing to lend a hand [if needed] as this subject is still of great relevance to me.
It's done in CVS. Caveat: Ralf is reporting some problems with his custom to_python converters, but so far I can't reproduce them. Unless you have made custom to_python converters, this probably won't affect you. -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
David Abrahams <dave@boost-consulting.com> writes:
"Nicolas Lelong" <n_lelong@hotmail.com> writes:
Hi,
I catch up late as you had this like exchange as I was sleeping :) All I can do is agree with everything you both came along !
I did not have time to complete the draft implementation I started in November but I'm still willing to lend a hand [if needed] as this subject is still of great relevance to me.
It's done in CVS.
Caveat: Ralf is reporting some problems with his custom to_python converters, but so far I can't reproduce them. Unless you have made custom to_python converters, this probably won't affect you.
We know what the problem is and have a workaround; it's nothing to worry about. -Dave -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Hi Dave, This worked straight out of the box. Thanks for all you help and fast response on this matter! Cheers, Daniel Paull
-----Original Message----- From: c++-sig-admin@python.org [mailto:c++-sig-admin@python.org] On Behalf Of Nicolas Lelong Sent: Saturday, 21 December 2002 2:41 AM To: c++-sig@python.org Subject: Re: [C++-sig] automatic downcasting with V2
It's done in CVS.
Great ! I'm eager to have a look at this :)
Nicolas.
_______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
Hello, I was building boost on alpha cluster using g++ and I get many errors of this sort: /usr/include/pthread.h:312:4: #error "Please compile the module including pthread.h with -pthread" I am wondering how to turn pthread on instead of tampering with gcc-tools.jam, and I am not sure how. There is a line in gcc-tools.jam: flags gcc CFLAGS <threading>multi : -pthread ; Thank you Chuzo
chuzo okuda <okuda1@llnl.gov> writes:
Hello, I was building boost on alpha cluster using g++ and I get many errors of this sort:
/usr/include/pthread.h:312:4: #error "Please compile the module including pthread.h with -pthread"
I am wondering how to turn pthread on instead of tampering with gcc-tools.jam, and I am not sure how.
There is a line in gcc-tools.jam:
flags gcc CFLAGS <threading>multi : -pthread ;
Adding "-sBUILD=<threading>multi" to your bjam command-line is one good way to achieve it. BTW, I was under the impression your group wasn't using Boost.Python anymore (?) -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Greetings, Does anyone know if there is an RPM around to install Boost(.Python) on a Linux box? If not, would that be a good thing to have, akin to the recently submitted MSVC++ project that builds it? It is not that I have any problems building it with Jam, that works quite smoothly. The reason I do ask: I just made an RPM of my own C++ software package and and am now thinking of making an RPM for this same package exported into Python using BP. The Pythonized package will depend upon BP and the RPM package manager would/should know that. Hence there should be a Boost.Python RPM that would install BP and satisfy that dependency (by registering itself in the RPM database). Scott
"Scott A. Smith" <ssmith@magnet.fsu.edu> writes:
Greetings,
Does anyone know if there is an RPM around to install Boost(.Python) on a Linux box?
Scott, meet Benjamin Koznik. Benjamin, Scott. Benjamin was just asking me the same question a few weeks back.
If not, would that be a good thing to have
Yes!
akin to the recently submitted MSVC++ project that builds it? It is not that I have any problems building it with Jam, that works quite smoothly.
The reason I do ask:
I just made an RPM of my own C++ software package and and am now thinking of making an RPM for this same package exported into Python using BP. The Pythonized package will depend upon BP and the RPM package manager would/should know that. Hence there should be a Boost.Python RPM that would install BP and satisfy that dependency (by registering itself in the RPM database).
Sounds like a good thing to have. -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
On Tue, 28 Jan 2003 18:28:32 -0500 David Abrahams <dave@boost-consulting.com> wrote:
"Scott A. Smith" <ssmith@magnet.fsu.edu> writes:
Greetings,
Does anyone know if there is an RPM around to install Boost(.Python) on a Linux box?
Scott, meet Benjamin Koznik. Benjamin, Scott. Benjamin was just asking me the same question a few weeks back.
If not, would that be a good thing to have
Yes!
Agreed. Scott, if you do this please let me know. -benjamin
Bejamin,
Scott, if you do this please let me know.
It appears someone has already done this. I have not yet checked them, but it apears that all of Boost & Jam have RPMs already built here: http://www.starostik.de/malte/boost Scott
[2003-02-03] Scott A. Smith wrote:
Bejamin,
Scott, if you do this please let me know.
It appears someone has already done this. I have not yet checked them, but it apears that all of Boost & Jam have RPMs already built here:
I also just started putting up binaries/RPMs of Boost.Jam on the SourceForge files distribution section. http://sourceforge.net/project/showfiles.php?group_id=7586 -- grafik - Don't Assume Anything -- rrivera@acm.org - grafik@redshift-software.com -- 102708583@icq
I've just installed gcc 3.3 and I get the following error g++ -DQT_THREAD_SUPPORT -I. -I../../hippodraw/python -I.. -I../../hippodraw -I../../hippodraw/qt -I../qt -I/usr/local/boost -ftemplate-depth-60 -I/usr/include/python2.2 -I/usr/lib/qt-3.1/include -g -O2 -Wall -c ../../hippodraw/python/QtCut.cxx -MT QtCut.lo -MD -MP -MF .deps/QtCut.TPlo -fPIC -DPIC In file included from /usr/local/boost/boost/config.hpp:35, from /usr/local/boost/boost/type_traits/config.hpp:14, from /usr/local/boost/boost/type_traits/is_same.hpp:14, from /usr/local/boost/boost/type_traits/same_traits.hpp:14, from /usr/local/boost/boost/python/cast.hpp:10, from /usr/local/boost/boost/python/handle.hpp:10, from /usr/local/boost/boost/python/args_fwd.hpp:9, from /usr/local/boost/boost/python/args.hpp:9, from /usr/local/boost/boost/python.hpp:12, from ../../hippodraw/python/QtCut.cxx:23: /usr/local/boost/boost/config/compiler/gcc.hpp:66:7: warning: #warning "Unknown compiler version - please run the configure tests and report the results" /usr/local/boost/boost/python/converter/as_to_python_function.hpp:31: sorry, unimplemented: ` method_call_expr' not supported by dump_expr I understanding the warning, but I get the error 4 times. Any ideas? P.S. To run the "configure tests" is it the $BOOST_ROOT/tools/regression/run_tests.sh script? I rebuilt boost_1_30_0 with gcc 3.3 and ran it. The results are at ftp://ftp.slac.stanford.edu/users/pfkeb/boost/
"Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU> writes:
I've just installed gcc 3.3 and I get the following error
/usr/local/boost/boost/python/converter/as_to_python_function.hpp:31: sorry, unimplemented: ` method_call_expr' not supported by dump_expr
I understanding the warning, but I get the error 4 times. Any ideas?
That's a compiler bug, plain and simple. You should report it to the gcc people: http://gcc.gnu.org/bugs.html. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Thu, 15 May 2003 18:53:50 -0400, David Abrahams <dave@boost-consulting.com> said:
"Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU> writes:
I've just installed gcc 3.3 and I get the following error
/usr/local/boost/boost/python/converter/as_to_python_function.hpp:31: sorry, unimplemented: ` method_call_expr' not supported by dump_expr
I understanding the warning, but I get the error 4 times. Any ideas?
That's a compiler bug, plain and simple. You should report it to the gcc people: http://gcc.gnu.org/bugs.html.
I commented out in boost/python/converter/as_to_python_function.hh BOOST_STATIC_ASSERT( sizeof( convert_function_must_take_value_or_const_reference(&ToPython::convert, 1L)) == sizeof(int)); and thing compiled and ran ok.
On Thu, 15 May 2003 18:53:50 -0400, David Abrahams <dave@boost-consulting.com> said:
"Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU> writes:
I've just installed gcc 3.3 and I get the following error
/usr/local/boost/boost/python/converter/as_to_python_function.hpp:31: sorry, unimplemented: ` method_call_expr' not supported by dump_expr
I understanding the warning, but I get the error 4 times. Any ideas?
That's a compiler bug, plain and simple. You should report it to the gcc people: http://gcc.gnu.org/bugs.html.
If I knew what the bug was, I would. Did this bug show up in one of the failed boost regression tests that I posted? If so, which one. Sending that test to the gcc people would be a lot more useful thatn how I can described the bug.
"Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU> writes:
On Thu, 15 May 2003 18:53:50 -0400, David Abrahams <dave@boost-consulting.com> said:
"Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU> writes:
I've just installed gcc 3.3 and I get the following error
/usr/local/boost/boost/python/converter/as_to_python_function.hpp:31: sorry, unimplemented: ` method_call_expr' not supported by dump_expr
I understanding the warning, but I get the error 4 times. Any ideas?
That's a compiler bug, plain and simple. You should report it to the gcc people: http://gcc.gnu.org/bugs.html.
If I knew what the bug was, I would.
What do you mean "what the bug was?" You don't have to diagnose the bug to report it. Any time you get an internal assertion failure from the compiler like that, all you have to do is post them a preprocessed file that reproduces it.
Did this bug show up in one of the failed boost regression tests that I posted? If so, which one.
Now I'm really confused. If you posted the regressions, surely you can go through them and look for that error message?
Sending that test to the gcc people would be a lot more useful thatn how I can described the bug.
Sure, can't you do that? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Sun, 18 May 2003 20:19:22 -0400, David Abrahams <dave@boost-consulting.com> said:
"Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU> writes:
> On Thu, 15 May 2003 18:53:50 -0400, David Abrahams > <dave@boost-consulting.com> said:
"Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU> writes:
I've just installed gcc 3.3 and I get the following error
/usr/local/boost/boost/python/converter/as_to_python_function.hpp:31: sorry, unimplemented: ` method_call_expr' not supported by dump_expr
I understanding the warning, but I get the error 4 times. Any ideas?
That's a compiler bug, plain and simple. You should report it to the gcc people: http://gcc.gnu.org/bugs.html. If I knew what the bug was, I would.
What do you mean "what the bug was?" You don't have to diagnose the bug to report it. Any time you get an internal assertion failure from the compiler like that,
Oh, the message is coming from the compiler. I thought it was coming from the BOOST_ASSERT on that line.
all you have to do is post them a preprocessed file that reproduces it.
Ok, I'm familer with that.
Did this bug show up in one of the failed boost regression tests that I posted? If so, which one.
Now I'm really confused. If you posted the regressions, surely you can go through them and look for that error message?
Sorry, I should have thought of that once I realize it was a compiler error. The answer is, no such error message from the regression tests.
Sending that test to the gcc people would be a lot more useful thatn how I can described the bug.
Sure, can't you do that?
Will do.
On Sun, 18 May 2003 20:19:22 -0400, David Abrahams <dave@boost-consulting.com> said:
What do you mean "what the bug was?" You don't have to diagnose the bug to report it. Any time you get an internal assertion failure from the compiler like that, all you have to do is post them a preprocessed file that reproduces it.
Its is GCC's GnatsWeb. Someone beat me to it.
Paul F Kunz writes:
On Sun, 18 May 2003 20:19:22 -0400, David Abrahams <dave@boost-consulting.com> said: What do you mean "what the bug was?" You don't have to diagnose the bug to report it. Any time you get an internal assertion failure from the compiler like that, all you have to do is post them a preprocessed file that reproduces it.
Paul> Its is GCC's GnatsWeb. Someone beat me to it. err.. yes, I did :) I had the same problem, but I only noticed now that there was a discussion about this here too.. cheers domi -- Bank error in your favor. Collect $200.
participants (11)
-
Benjamin Kosnik -
chuzo okuda -
Daniel Paull -
David Abrahams -
Dominique Devriese -
Greg Landrum -
greg Landrum -
Nicolas Lelong -
Paul F. Kunz -
Rene Rivera -
Scott A. Smith