Mailman 3 July 2003 - Cplusplus-sig

Pyste: patch for HeldType and sys.path.
by Prabhu Ramachandran July 7, 2003

July 7, 2003

Hi, Attached is a patch to Pyste that allows one to specify the HeldType template argument for class_. I've only added auto_ptr and shared_ptr support. They can be used by doing something like so: A = Class('test::A', header.hpp') hold_with_auto_ptr(A) # alternatively hold_with_shared_ptr(A) I've also changed pyste.py to modify sys.path such that the directories containing the Pyste interface files are in the path. This makes it easy to import a Python module that could define functions for commonly used functionality (like generating simple wrappers). cheers, prabhu

2 1

pyste and functions returning opaque pointers
by Gottfried Gan�auge July 7, 2003

July 7, 2003

Hi, i am wrapping a C library containing several functions returning opaque pointers. When i wrap several functions returning the same opaque pointer, the BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID-Makro for the pointer type is issued as many times as I'm having functions returning the same pointer type. Consider the following source: ggbug.h ===== typedef struct anonymous *type1; type1 f1(); type1 f2() ggbug.pyste ======== h = AllFromHeader("ggbug.h") set_policy ( h.f1, return_value_policy(return_opaque_pointer)) set_policy ( h.f2, return_value_policy(return_opaque_pointer)) "pyste ggbug.pyste" produces the following ggbug.cpp ======= // Includes ==================================================================== #include <boost/python.hpp> #include <ggbug.h> // Using ======================================================================= using namespace boost::python; // Declarations ================================================================ BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(anonymous)BOOST_PYTHON_OPAQUE_SPECIA LIZE D_TYPE_ID(anonymous) // Module ====================================================================== BOOST_PYTHON_MODULE(ggbug) { def("f1", &f1, return_value_policy< return_opaque_pointer >()); def("f2", &f2, return_value_policy< return_opaque_pointer >()); } I think that one of the BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(anonymous)'s shouldn't be there Cheers, Gottfried Ganßauge

2 1

Problem with embedding python with boost.python
by Pierre Barbier de Reuille July 7, 2003

July 7, 2003

I try to embed python in a C++ program. I wrote a module that works if I compile it for extending python ... and I wrote a simple interpreter that works as an embedded one ! But now I want to extend the embedded interpreter to allow access to the C++ classes ! The extension module is called "editor". My problem is that whenever I try to import the module in python, the program just abort ... the import is done by evaluating 'import edtitor' inside the python interpreter ... I show you the interpreter code ! Of course, the module is defined using boost.python ! An extra-question is : if I use Py_file_input, I can't retrieve the output of the python command, if I use Py_single_input, I can retrieve the output, but I can't do any assignment or printing ... how can I have both ??? I really begin to think python was not designed to embedded :( Tthe interpreter class is : class PythonWnd : public QMainWindow { Q_OBJECT public: PythonWnd(QWidget * parent = 0, const char * name = 0, WFlags f = WType_TopLevel); ~PythonWnd(); public slots: void evalCommand(); protected: void LaunchPython(); void ClosePython(); void ExecutePython(const QString command); QTextEdit *output; QLineEdit *edit; QVBox *layout; boost::python::object main_module; boost::python::dict main_namespace; }; The initialization function that is : void PythonWnd::LaunchPython() { // register the module editor with the interpreter if (PyImport_AppendInittab("editor", init_module_editor) == -1) { cerr << "Error, cannot load editor module !" << endl; throw std::runtime_error("Failed to add embedded_hello to the interpreter's " "builtin modules"); } // Initialize the interpreter Py_Initialize(); // Get the main module ... main_module = object(boost::python::handle<>(borrowed(PyImport_AddModule("__main__")))); main_namespace = dict(boost::python::handle<>(borrowed(PyModule_GetDict(main_module.ptr())))); } Then the interpretor function (launched each time a line is to be evaluated ... it's an iteractive interpretor) is: void PythonWnd::ExecutePython(const QString command) { char *cmd; cmd = new char[command.length()+1]; strcpy(cmd, command.latin1()); stringstream ss; try { PyObject *obj = PyRun_String(cmd, Py_file_input, main_namespace.ptr(), main_namespace.ptr()); boost::python::handle<> hres(obj); boost::python::object res(hres); //std::string res_cmd = extract<std::string>(res.attr("__repr__")()); std::string res_cmd = call_method<std::string>(res.ptr(),"__repr__"); ss << res_cmd; } catch(error_already_set) { PyErr_Print(); ss << "Error, exception thrown ... look at console for details" << endl; PyObject *exception, *v, *tb, *hook; } output->append(ss.str().c_str()); delete cmd; } -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68

2 4

deriving in python from a C++ base class
by Stefan Seefeld July 6, 2003

July 6, 2003

hi there, I have trouble extending a demo from the tutorial (taken from http://www.boost.org/libs/python/doc/tutorial/doc/exposing_classes.html). Instead of just instantiating objects of type 'World' in python, I subclass 'World' first, making calls to base class methods from the constructor: class MyWorld(World): def __init__(self): self.set('hi there') print self.greet() that ought to be possible (or so I thought), but instantiating a 'MyWorld' object (still inside python) yields: Traceback (most recent call last): File "test.py", line 18, in ? world = MyWorld() File "test.py", line 10, in __init__ self.set('hi there') TypeError: bad argument type for built-in operation Reading on in the tutorial I find some information about polymorphism on http://www.boost.org/libs/python/doc/tutorial/doc/class_virtual_functions.h…, but that page explicitely states that the use of auxiliary wrapper classes is only needed in case I want to access the virtual (python overridden) methods from within C++, which is not (yet) my case, i.e. as far as I'm aware of in my little test there isn't any form of polymorphism involved. What am I missing ? Thanks, Stefan

4 11

Pyste: feature requests
by Prabhu Ramachandran July 6, 2003

July 6, 2003

Hi, I've been trying to wrap a fairly large library of mine using Boost.Python. I've been using Pyste to generate the wrapper code. Since the library is large, I've been using Pyste's --multiple option. Something like this: pyste.py --module=test --out build --multiple file1.pyste file2.pyste I find a few inconveniences and difficulties with this approach and it would be nice to have the following features: 1. Something like the C compiler's '-c' option. In this case Pyste should simply generate the wrapper code and none of the module code i.e. for an invocation like so: pyste.py --out build --multiple -c file1.pyste nothing should be added to test.cpp and just a _file.cpp (or whatever) should be generated which can be then compiled. Then invoking pyste.py --module=test --out build/ --multiple file1.pyste \ file2.pyste should generate test.cpp with the appropriate code. This makes it much easier to handle dependencies. Perhaps the option should be called '-w' for 'just-wrap'? 2. Instead of generating files for each header, it would be useful if one file were generated per pyste file when --multiple were used. The trouble with the current approach of --multiple is that several files can be generated per pyste file. This causes problems with dependencies since one does not (easily) know apriori what files will be generated. For example changing -D options could change the number of files generated. Perhaps instead of changing the behaviour of the --multiple option one one could add another option called --one-file (with a better name). Alternatively if the argument to --out is a filename (file.cpp) that may or may not exist then that file is written, if the argument is a directory (which exists) then multiple files can be generated in that directory. I think these options or something along these lines would make life easier when wrapping larger libraries. What do you folks think? Thanks! cheers, prabhu

2 7

Random access iterators, and sequence protocol.
by Prabhu Ramachandran July 6, 2003

July 6, 2003

Hi, I have a container class that defines an operator [] (std::size_t) and also has a size function that returns the number of elements in the container. It does not provide access to an internal iterator. To get the '[]' wrapped with Pyste I need to rename the function as __getitem__ of course. I also renamed size to __len__. However, I would like to do this: for i in container: i.something() To do this __getitem__ needs to generate an IndexError when the index is greater than or equal to size. Do I _have_ to register an exception translator from something like std::range_error? Is there an easier way to do this? The docs don't reveal any easier solutions. It would be nice if this were also as easy as doing it via range, or iterator. :) Thanks. cheers, prabhu

4 7

Pyste: bug: overriding overloaded virtual functions.
by Prabhu Ramachandran July 5, 2003

July 5, 2003

Hi, One more bug. Consider an overloaded virtual function that is implemented in the base class and not overridden in the derived class. // --------- overload.hpp -------- namespace test { class Base { public: virtual void f() {} virtual void f(const int i){} }; class A : public Base { public: void f(){} }; } // --------- overload.hpp -------- Running Pyste on this produces this wrapper code: // ---------- wrapper code ---------- struct test_A_Wrapper: test::A { [...] void f(const int p0) { call_method< void >(self, "f", p0); } void default_f(const int p0) { test::A::f(p0); // <<=========== ERROR. test::Base::f(p0); // <<=========== Should be this. } [...] // ---------- wrapper code ---------- Attached is a patch (two lines) for the _current_ CVS code that fixes this. cheers, prabhu

2 4

Installing Pyste.
by Prabhu Ramachandran July 5, 2003

July 5, 2003

Hi, Before starting to use Pyste I wanted to install it in a common location instead of running it off Boost's CVS tree. I find it easier to manage packages when I can install them somewhere. To this end I wrote a trivial setup_pyste.py using distutils that works. Its not great but works. Here is what I did: Use the following setup_pyste.py # -------------------- import os from distutils.core import setup boost_base_dir = "/path/to/your/boost/dir" pyste_src_dir = os.path.join(boost_base_dir, "libs/python/pyste/src") setup (name = "Pyste", version = "1.0", description = "Pyste - Python Semi-Automatic Exporter", maintainer = "Bruno da Silva de Oliveira", maintainer_email = "nicodemus(a)globalite.com.br", licence = "Boost License", long_description = "Pyste is a Boost.Python code generator", url = "http://www.boost.org/libs/python/pyste/index.html", platforms = ['Any'], packages = ['Pyste'], scripts = ['pyste.py'], package_dir = {'Pyste': pyste_src_dir} ) # -------------------- This installs Pyste inside <prefix>/site-packages/Pyste. I wrote a simple wrapper pyste.py script to use this like so: # -------------------- #!/usr/bin/env python import time import sys from Pyste import pyste if __name__ == '__main__': start = time.clock() pyste.UsePsyco() status = pyste.Main() print '%0.2f seconds' % (time.clock()-start) sys.exit(status) # -------------------- Make this executable and finally do: python setup_pyste.py install to install Pyste. Finally add a __init__.py into <prefix>/site-packages/Pyste. It would be nice if something like this were included the repository. Thanks for Boost.Python and Pyste! cheers, prabhu

2 6

Re: [C++-sig] Re: Interest in luabind
by Daniel Wallin July 5, 2003

July 5, 2003

> "Daniel Wallin" <dalwan01(a)student.umu.se> writes: > > >> "Daniel Wallin" <dalwan01(a)student.umu.se> writes: > > > > The type of the type-identifier needs to be known to the > > library though, so my point is that it can't be a > template > > which the user just specializes. You also need to set > the > > type for the compiled part of the library. Or am I > missing > > something here? > > Probably not; I think you have a good point, at least, if > we > need runtime polymorphism among type id objects or if they > need to be manipulated in the compiled part of the > library. > > typedefs still work, though. Yeah, a typedef would have been a much better solution. I think the reason we use macro's is because we used const type_info* directly, instead of wrapping it in a class. So we couldn't simply use < and == when comparing the types. > > >> >> >> > This of course causes some problems if we want > to > >> >> >> > downcast > >> >> >> > >> >> >> And if you want to support CBD (component based > >> >> >> development, i.e. cross-module conversions), > unless > >> >> >> you can somehow get all authors to agree on how > to > >> >> >> identify types. Well, I guess they could use > >> >> >> strings and manually supply what > >> >> >> std::type_info::name() does. > >> >> > > >> >> > It doesn't seem wrong that the authors need to use > the > >> >> > same typeid. If you aren't developing a closed > system, > >> >> > don't change typeid system. > >> >> > >> >> I was thinking more of id collisions among > extensions > >> >> which don't intend to share types. It becomes less > of an > >> >> issue if people use string ids. > >> > > >> > But like I said, if you intend to use your module > with other > >> > modules; don't change the typeid system. > >> > >> I'm not talking about changing systems, just the need > to > >> ensure unique type IDs for different types across > modules. > > > > Yeah I know, what I'm saying is that you will only get > > problems like that if you change your type_info > > represantation to something like 'int'. In which case > you > > have changed type id system. This isn't a problem as > long > > as you stick to typeid() and type_info? > > Assuming a single compiler and the use of distinct > namespaces, no. Right. > > >> >> > LUABIND_DONT_COPY_STRINGS > >> >> > >> >> What kind of string copying gets disabled? > >> > > >> > It causes names to be held by const char* instead of > >> > std::string. (class names, function names etc). > >> > >> Why not always do that? > > > > Hold const char*? Because you can't control their > > lifetime? :) > > You mean that some people want to compute these things > dynamically instead of using string literals? Nobody has > ever asked me for that. I bet this is one area of > configurability that could be dropped. We actually have one user that uses this feature, I don't know if he actually needs to though. So yeah, it could probably be dropped. > >> > Need to think about this some more. It's no special > >> > case in BPL though, it's just another type of > >> > instance_holder, correct? > >> > >> Not only that. It's an issue of where the instance > holder > >> gets constructed. In this case it is constructed > directly > >> in the storage for the Python object. > > > > Right, that's pretty cool. > > Yeah, but I doubt it's saving much, and it leads to much > complication (c.f. instance_new and instance_dealloc in > libs/python/src/object/class.cpp). If objects are getting > created and destroyed a *lot* it could reduce > fragmentation > and increase locality... but as I said I have big doubts. Yeah, fragmentation issues can always be solved with pool allocation. Is the complexity only due to value-holders, or just different kind of holders? Seems to me (without having looked at instance_new/instance_dealloc yet..) like you would need the same allocation routines for pointer-holders as well. > >> The to-python converter that gets registered for > >> auto_ptr<T> by using it in a class<T, std::auto_ptr<T>, > >> ... > or by using > >> register_pointer_to_python<std::auto_ptr<T> > knows > what > >> to do. > > > > Ah, right. It's pretty nice to be able to hold the > instances > > in different kind of holders. > > Yeah. > > Note also that shared_ptr is "magic", in that any wrapped > T > can be converted to shared_ptr<T> regardless of holder, > and > the resulting shared_ptr<T> can be converted back to the > original Python object (not just a new one sharing the > same > C++ object). Ok. I noticed that while browsing the code. The custom deleter is a powerful tool. :) > >> > and even the > >> > ones that doesn't can still be used in different > contexts. > >> > ('result' when doing C++ -> lua, and '_N' when doing > lua -> > >> > C++). > >> > >> How is that *not* a case of bidirectionality? > > > > :) It is, my fault. I meant it could be used in > different > > contexts with the same direction, it should read > something > > like: 'result' when calling a C++ function, '_N' when > > calling a lua function. > > > >> That rule makes me nervous, because the terms are > >> backwards when calling lua/python from C++. Do people > >> get confused? > > > > I don't think they do, I don't think anyone has reported > any > > problems with it yet. It's backwards for a reason > though, > > and it's pretty clear when to use which placeholder. > (except > > in some special cases, where documentation helps). > > OK. Maybe we could allow a default argument which would > "just work" for these cases. Another option is "_", which > is used in MPL for something similar. Sure, that would be nice. You can also introduce additional placeholder aliases for the cases where '_N' and 'result' doesn't fit very well. -- Daniel Wallin

6 21

Problems with Pyste from CVS.
by Prabhu Ramachandran July 5, 2003

July 5, 2003

Hi, I just updated my local CVS checkout of Boost. I tried running Pyste and got the following traceback. The same exact pyste file worked fine a little while earlier with an older checkout (June 25th) of CVS. If you need any more information let me know. I can also try and generate a smaller test case that I can include here (right now I don't have one). Thanks. prabhu -------------------------------------------------- Traceback (most recent call last): File "/usr/local/bin/pyste.py", line 11, in ? status = pyste.Main() File "/usr/local/stow/pyste/lib/python2.2/site-packages/Pyste/pyste.py", line 195, in Main declarations, parsed_header = parser.parse(header, all_tails) File "/usr/local/stow/pyste//lib/python2.2/site-packages/Pyste/CppParser.py", line 82, in parse declarations = ParseDeclarations(xmlfile) File "/usr/local/stow/pyste/lib/python2.2/site-packages/Pyste/GCCXMLParser.py", line 437, in ParseDeclarations parser.Parse(filename) File "/usr/local/stow/pyste/lib/python2.2/site-packages/Pyste/GCCXMLParser.py", line 36, in Parse self.ParseElement(id, element) File "/usr/local/stow/pyste/lib/python2.2/site-packages/Pyste/GCCXMLParser.py", line 60, in ParseElement func(id, element) File "/usr/local/stow/pyste/lib/python2.2/site-packages/Pyste/GCCXMLParser.py", line 371, in ParseOperatorMethod self.ParseMethod(id, element, ClassOperator) File "/usr/local/stow/pyste/lib/python2.2/site-packages/Pyste/GCCXMLParser.py", line 356, in ParseMethod classname = self.GetDecl(element.get('context'))._FullName() File "/usr/local/stow/pyste/lib/python2.2/site-packages/Pyste/GCCXMLParser.py", line 98, in GetDecl self.ParseElement(id, elem) File "/usr/local/stow/pyste/lib/python2.2/site-packages/Pyste/GCCXMLParser.py", line 60, in ParseElement func(id, element) File "/usr/local/stow/pyste/lib/python2.2/site-packages/Pyste/GCCXMLParser.py", line 291, in ParseClass class_._AddMember(member) File "/usr/local/stow/pyste/lib/python2.2/site-packages/Pyste/declarations.py", line 123, in _AddMember m._is_unique = False AttributeError: 'str' object has no attribute '_is_unique'

3 8